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ABSTRACT 


Product  maintenance  is  becoming  more  expensive  due  to  the  increasing 
complexity  of  both  product  design  and  associated  maintenance  requirements.  In  order  to 
build  the  reliability,  maintainability,  and  supportability  characteristics  into  a  product  at 
minimum  life-cycle  costs,  a  structured  methodology  should  be  used  to  facilitate  the  early 
identification  and  integration  of  these  characteristics  in  the  product  design,  to  develop 
the  most  effective  product  support  concepts,  and  to  define  the  product  support  resource 
requirements. 

To  achieve  these  objectives,  cm  integrated  data  base  is  required  to  integrate 
logistic  related  engineering  information.  The  ISO  STEP  Product  Logistic  Support  (PLS) 
Application  Protocol  suite  (APs)  now  under  development  is  proposed  to  define  the  data 
requirements  for  ensuring  reliable,  maintainable,  and  supportable  products  at  minimum 
cost  by  integrating  logistic  support  considerations  into  the  evolving  design, 
manufacturing,  and  support  efforts.  The  development  of  the  PLS  APs  will  be  based 
primarily  on  the  integration  of  V.S.  CALS  LSAR  and  lETMDB  standards  and  on  the 
European  AECMA  2000M  and  lOOOD  specifications. 


ADMINISTRATIVE  INFORMATION 


The  Advanced  Infonnation  System  Branch  (Code  183)  of  the  Communications  and 
Information  Systems  Department  at  the  Carderock  Division ,  Naval  Surface  Warfare  Center, 
proposed  and  completed  this  woric.  under  sponsorship  of  the  Navy  CALS  Coordination  Office. 
This  work  was  performed  under  NSWC  project  number  1830-440. 


The  opinions  expressed  in  this  report  are  those  of  the  author.  They  do  not  necessary 
reflect  the  views  of  the  Department  of  the  Navy. 
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EXECUTIVE  SUMMARY 


Due  to  the  lack  of  international  standards  for  the  logistic  support  of  product  data 
exchange,  it  is  becoming  increasingly  difficult  to  attain  optimal  data  management  (transmitting, 
accessing,  and  updating)  of  the  enormous  amounts  of  data  for  modem  product  systems  (such  as 
weapon  systems)  throughout  their  life  cycle. 

Continuous  Acquisition  and  Life-cycle  Support  (CALS)  is  a  Department  of  Defense 
(DoD)  initiative  to  facilitate  enterprising  integration  and  to  promote  an  electronic  commerce 
environment  to  enhance  industrial  competitiveness  and  economic  growth  through  process 
improvement,  information  integration,  and  data  exchange  standards. 

ISO  STEP  is  an  international  standard  designed  to  give  a  complete  computer- 
interpretable  representation  of  product  data  in  a  neutral  format  throughout  the  complete  product 
life  cycle.  This  representation  makes  it  suitable  not  only  for  file  exchange  but  also  as  a  basis  for 
implementing,  sharing,  and  archiving  product  data  bases. 

The  STEP  standards  are  fundamental  to  die  CALS  effort.  The  STEP  shared  data 
environment  will  provide  the  kernel  of  the  IPDB/IWSDB.  As  STEP  evolves,  it  will  provide  a 
major  pcHtion  of  the  functional  framework  for  the  IPDB/IWSDB.  Due  to  the  rapid  international 
acceptance  of  the  CALS  initiative  and  the  worldwide  agreement  of  STQ*  as  the  future  product 
data  exchange,  more  resources  should  be  invested  in  the  development  of  STEP  standards. 

The  pilot  PLS  APs  are  designed  as  a  part  of  the  STEP  standards  for  the  implementation 
of  a  shared  integrated  data  base  environment  for  LSAR,  TM,  parts  provisioning ,  and  order 
administration.  The  goals  of  this  data  base  environment  are  to:  (1)  ensure  reliable,  maintainable, 
and  sujqxHtable  products  at  minimum  life-cycle  cost;  (2)  harmonize  existing  AECMA 
specifications,  CALS  standards,  and  other  national  and  international  standards  in  the  logistic 
support  area;  and  (3)  meet  both  industrial  and  military  requirements.  The  pilot  PLS  APs  effort 
(which  can  be  implemented  in  about  three  years)  will  focus  only  on  air  vehicles.  After  the 
completion  of  and  lessons  learned  from  this  pilot  development  effort,  the  scope  of  the  pilot  PLS 
APs  can  be  extended  to  land  and  sea  vehicles  and  to  other  product  areas. 
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In  cooperation  with  the  CALS/CE ISG  SALSA  committee  and  other  European 
representatives  who  were  attending  the  CALS  Expo  93  convention,  a  draft  of  the  pilot  PLS  APs 
requirements  has  been  prepared,  it  is  attached  as  Appendixes  E  and  F.  This  report  also  suggests 
the  implementation  plan  for  PLS  APs. 

The  chief  benefit  for  the  U.S.  participation  in  the  development  of  PLS  APs  would  be  that 
of  ensuring  full  consideration  of  U.S.  military  and  industry  requirements  to  be  included  in  this 
international  PLS  APs  standards.  This  will  favor  U.S.  industry  in  world  market  competition  and 
enhance  foreign  military  sales. 


1.0  INTRODUCTION 


1.1  Purpose 

The  purpose  of  this  report  is  to  describe  the  requirements,  strategy,  and  plans  for 
developing  a  pilot  effort  of  an  ISO  (International  Organization  for  Standardization)  STEP 
(STandard  for  the  Exchange  of  Product  data  model)  standard  -  the  Product  Logistic  Support 
(PLS)  Application  Protocol  (AP)  suite.  This  pilot  PLS  AP  suite  prototyping  effort,  limited  in 
scope,  can  currently  be  implemented  in  a  relatively  short  period  of  time  (three  years). 

1.2  Objectives 

The  objective  of  the  pilot  PLS  APs  project  is  to  develop  ISO  STEP  standards  for 
representing  and  exchanging  information  with  regard  to  product  logistic  support  in  order  to 
achieve  the  following  goals:  (1)  to  establish  the  information  requirements  for  ensuring  reliable, 
maintainable,  and  supportable  products  at  minimum  life-cycle  cost  by  integrating  data  bases  for 
Logistic  Support  Analysis  Records  (LSARs),  technical  manuals  (TMs),  provisioning,  and  order 
administration;  (2)  to  harmonize  existing  European  AECMA  (Association  European  des 
Constructeurs  de  Materiel  Aerospatial)  specifications,  U.S.  CALS  (Continuous  Acquisition  and 
Life-cycle  Support)  standards,  and  other  national  and  international  standards  in  the  acquisition 
logistic  area;  and  (3)  to  meet  both  industry  and  military  requirements. 
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The  pilot  PLS  APs  are  designed  as  part  of  the  ISO  STEP  standards  for  the 
implementation  of  a  conunon  and  shared  integrated  data  base  environment  for  LSARs,  TMs,  parts 
provisioning ,  and  order  administration. 

1.3  Scope 

The  scope  of  the  pilot  PLS  APs  project  is  to  define  the  information  requirements  for 
acquisition  and  logistic  support  in  the  functional  areas  of: 

o  LSAR, 

o  TM, 

o  Provisioning,  and 

o  Order  administration. 

The  development  of  the  pilot  PLS  APs  will  primarily  be  based  on  the  existing  national 
and  international  standards  in  the  acquisition  and  logistic  support  areas.  This  will  be 
accomplished  by  drawing  upon  the  efforts  that  are  being  performed  by  NATO  (North  Atlantic 
Treaty  Oiganization),  CALS  (Continuous  Acquisition  and  Life-cycle  Support),  AECMA,  ANSI, 
and  ISO  standards.  By  integrating  and  harmonizing  efforts  into  the  STEP  environment,  this 
project  will  provide  the  ISO  STEP  community  with  operational  product  support  capabilities. 

Some  of  the  standards  upon  which  this  work  will  be  based ,  such  as  AECMA  1(X)0D  and 
20(X)M,  were  developed  specifically  for  the  use  of  air  vehicles  acquisition  and  support.  Therefore, 
this  pilot  PLS  APs  prototyping  effort  (which  should  be  implemented  in  about  three  years)  will 
also  focus  on  air  vehicles.  After  completing  the  work  and  assimilating  the  information  gained 
from  this  pilot  development  effort,  the  scope  of  the  pilot  PLS  APs  can  be  expanded  to  include 
land  and  sea  vehicles  as  well  as  other  product  areas  at  a  later  time. 


2.0  GLOSSARY 


A  glossary  is  provided  in  Appendix  A. 
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3.0  REFERENCED  DOCUMENTS 


A  list  of  "Referenced  Documents"  is  provided  in  Appendix  B. 


4.0  PILOT  PLS  APS  DEVELOPMENT 


This  section  describes  the  needs,  requirements,  strategies,  and  plans  required  to  develop 
the  prototype  pilot  PLS  APs  for  aircraft  acquisition  and  logistic  support. 

4.1  Global  Industrial  Needs 

Due  to  the  lack  of  both  international  product  data  exchange  standards  and  supporting  data 
transferring  infrastructures,  it  is  becoming  increasingly  difficult  for  geographically  distant 
partners  in  a  given  project  to  attain  optimal  data  management  for  transmitting,  accessing,  and 
updating  the  enormous  amounts  of  data  for  modem  product  systems  (such  as  weapon  systems) 
throughout  their  life  cycle.  The  exchange  of  product  information  needs  to  be  enhanced, 
international  data  exchange  standards  must  be  developed,  and  a  modem  data  transfer 
infrastructure  must  be  built. 

4.1.1  World  Product 

National  borders  mean  less  and  less  in  world  trade  and  industry.  Industry  is  trying  new 
ways  to  integrate  global  design,  manufacturing,  and  marketing  in  order  to  provide  leverage  of 
resources,  maximize  investments,  reduce  product  unit  costs,  sell  more  products,  balance 
currencies,  and  better  satisfy  local  markets.  Building  a  "world  product”  -  one  that  can  be 
designed,  manufactured,  supported,  and  marketed  around  the  globe  -  is  an  ambitious  goal  for 
industry,  because  it  represents  the  ultimate  goal  in  terms  of  economic  benefit.  The  current  global 
environment  carmot  effectively  support  such  an  ambitious  endeavor  as  designing,  manufacturing, 
marketing,  and  supporting  a  world  product. 
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For  example,  the  28  June  1993  issue  of  "Fortune"  reported  that  Ford  will  introduce  a 
midsize  car  model  "Mondeo"  in  1994,  a  "world  car."  Ford  spent  $6  billion  and  eight  years  on  its 
development  -  twice  the  usual  cost  and  time  required  to  bring  a  new  car  model  to  the  market.  This 
is  due  in  part  to  the  lack  of  international  product  exchange  standards  and  a  supporting  information 
exchange  infrastructure.  Six  billion  dollars  is  twice  what  Ford  spent  on  developing  the  successful 
Taurus  and  Sable  models.  In  the  case  of  the  Mondeo  model.  Ford  had  to  both  reconcile  divergent 
European  and  American  engineering  standards  and  spend  tens  of  millions  of  dollars  on  late 
design  changes.  Ford  had  to  develop  its  own  uniform  standards  for  the  designing,  engineering, 
procuring,  manufacturing,  supporting,  and  marketing  of  the  product. 

4.1.2  Product  Data  Exchange  Standards 

Product  data  exchange  is  one  of  the  fundamental  requirements  for  industry  and 
commerce.  It  is  also  not  adequately  understood.  Everyone  knows  how  to  send  a  letter  or  make  a 
phone  call;  very  few  know  how  to  send  product  data. 

When  more  and  more  workstations  and  networks  are  installed,  more  and  more  data  are 
produced.  However,  users  often  find  out  that  they  cannot  exchange  data  with  vendors,  customers, 
suppliers,  and  even  their  own  nearby  co-workers.  This  is  not  merely  a  technological  problem, 
because  they  do  not  have  compatible  data  formats  and  data  exchange  protocols. 

Those  enterprises  that  can  communicate  rapidly  and  accurately  will  have  a  competitive 
edge.  Those  that  can  integrate  and  address  their  customers'  and  suppliers'  needs  in  their 
engineering  and  manufacturing  data  will  gain  an  enormous  advantage.  The  ability  of  vendors, 
manufacturers,  and  suppliers  to  receive  and  supply  product  information  will  provide  a 
competitive  edge.  This  requires  both  international  data  standards  and  protocols  as  well  as  a 
telecommunication  infrastructure  to  transmit  the  data. 

As  distances  become  less  significant  through  new  communication  technologies,  the  need 
for  creating  compatible  national  and  international  standards  for  product  support  increases.  More 
and  more  countries  are  opening  their  borders  to  international  commerce.  This  necessitates  the 
develqiment  of  common  product  data  exchange  standards. 
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4. 1 .3  Acquisition  and  Logistic  Support 

Product  maintenance  is  becoming  more  expensive  due  to  the  increasing  complexity  of 
both  product  design  and  associated  maintenance  requirements.  In  order  to  build  the  reliability, 
maintainability,  and  supportability  characteristics  into  a  product  design,  a  struct^ ved  methodology 
(see  Section  4.2.4)  should  be  used  by  systems  engineering  to  facilitate  the  early  identification  and 
integration  of  these  characteristics  in  the  product  design,  to  develop  the  most  effective  product 
support  concepts,  and  to  define  the  product  support  resource  requirements. 

International  commerce  and  government  activities  do  not  have  standardized  procedures 
for  exchanging  Product  Logistic  Support  information.  There  is  a  strong  need  to  communicate 
supply  support  or  provisioning  information.  Today’s  "Just  in  Time"  support  environments  depend 
upon  the  rapid  procurement  of  parts  and  supplies.  This  requires  that  the  communication  of 
procurement  requirements  be  integrated  with  an  enterprise's  product  definition  data  bases. 
Accordingly,  an  integrated  data  base  is  required  to  integrate  logistics  related  engineering 
information.  The  pilot  PLS  APs  are  proposed  to  meet  these  needs. 

4.2  Related  Initiatives  and  Development 

In  the  last  decade  or  so,  several  relevant  initiatives  have  been  undertaken  with  regard  to 
improving  the  acquisition  and  logistic  processes  and  product  data  exchange. 

Figure  1  (from  Ref.  62;  see  Appendix  B)  shows  how  CALS  relates  to  other  initiatives, 
standards,  processes,  networks,  and  environments. 
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ContIniioiM  Acquisition  and 
Ufs-oyeis  Supp^ 

Concurrsnt  Enginssring 

Eisetronic  Data  Intsiehanga/ 

Standard  for  The  Exchange 
of  Product  data 

National  Super  High  way/ 

National  Information 
Initiative 

Entarprisa  Integration/ 

Coipwats  Information 
Managamant 

Fig.  1.  CALS  ralatlonship  with  othar  aeflvitias. 

4.2.1  Continuous  Acquisition  and  Life-cycle  Support  (CALS) 

The  Continuous  Acquisition  and  Life-cycle  Support  (CALS),  formerly  "Computer-aided 
Acquisition  and  Logistic  Support,"  initiative  was  formalized  by  DoD  in  1985  to  facilitate  the 
integration  of  digital  technical  information  for  weapon  system  acquisition,  design,  manufacture, 
and  support  functions.  CALS  addresses  requirements  for  an  orderly  transition  from  a  paper  and 
labor-intensive  environment  to  the  use  of  integrated  digital  technical  information  for  design, 
manufacturing,  and  support  processes.  CALS  technical  information  is  generated  once,  stored 
electronically  for  access,  and  transferred  in  neutral  formats:  thereby  making  the  information 
easily  available  to  any  legitimate  user  of  the  data.  The  objectives  of  the  CALS  program  are:  (1)  to 
REDUCE  LEAD  TIMES  for  creating,  transferring,  managing,  and  accessing  technical 
information  used  to  produce  and  maintain  weapon  systems;  (2)  to  IMPROVE  THE  QUALITY  of 
the  technical  information;  and,  cldmately,  (3)  to  REDUCE  THE  COST  associated  with  creating, 
transferring,  managing,  and  accessing  technical  data.  To  achieve  these  CALS  objectives,  a  phased 
strategy  has  been  established. 

The  CALS  strategy  is  to  facilitate  enterprising  integration  and  promote  an  electronic 
commerce  environment  to  enhance  industrial  competitiveness  and  economic  growth  through 
process  improvement,  information  technology,  and  international  product  data  exchange  standards. 
To  attain  these  goals,  the  following  are  required:  (1)  a  conunon  integrated  product  data  base 
(IPDB)  which  is  often  referred  to  in  DoD  as  an  Integrated  Weapon  System  Data  Base  (IWSDB); 
(2)  process  re-engineering,  i.e.,  application  of  concurrent  engineering  (CE)  principles;  (3)  an  open 
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systems  environment  of  product  data  exchange  using  the  evolving  data  exchange  standards,  STEP 
and  EDI;  and  (4)  an  information  infrastructure,  i.e.,  electronic  highway.  These  will  result  in  a 
faster  time  to  the  market,  improved  acquisition,  better  quality  products  and  product  support,  along 
with  lower  life-cycle  product  and  support  costs. 

The  CALS  shared  data  environment,  IPDB/IWSDB,  will  be  created  by  applying  the  best 
technologies,  processes,  and  standards  for  the  development,  management,  exchange,  and  use  of 
business  and  technical  information  among  government  activities  and  industrial  enterprises. 


OovamiMnt  and  Contractor  Dears 


Figure  2  shows  the  IPDB/IWSDB  operations  concept.  Data  sharing  is  at  the  heart  of  the 
operations  concept.  The  IPDB/IWSDB  will  provide  the  user  with  the  ability  to  obtain  all  needed 
technical  and  business  information  from  a  single  workstation.  The  technical  information  will  most 
likely  be  physically  located  in  many  different  places.  The  development  and  implementation  of  the 
IPDB/IWSDB  involves  the  following  issues:  (1)  defining  the  types  of  information  (functions)  to 
be  included;  (2)  specifying  user  operational  environments;  and  (3)  determining  an  effective 
implementation  of  the  IPDB/IWSDB. 

Figure  3  shows  the  implementation  of  IPDB/IWSDB  which  will  be  defined  in  terms  of 
conceptual  and  external  schemes.  The  conceptual  scheme  is  produced  by  way  of  data  modeling 
and  identifies  what  kinds  of  data  should  be  stored.  The  conceptual  scheme  defines  the  data  in  an 
integrated,  consistent,  and  neutral  format,  which  is  not  dependent  on  the  characteristics  of  any 
proprietary  data  base  management  system.  The  conceptual  scheme  also  defines  referential 
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integrity  and  supports  the  business  rules  of  the  organization  which  owns  the  data.  The  external 
scheme  describes  the  user's  view  of  the  data.  These  views  are  typically  represented  by  tabular  and 
matrix  arrangements  of  data  items. 


Fig.  3.  IPOBAWSOB  Implwmntillofi. 

For  a  successful  implementation  of  CALS,  the  following  three  things  are  required:  (1) 
industry  must  modernize  its  procedures  for  creating  technical  information  in  digital  format,  (2) 
DoD  must  modernize  its  procedures  for  receiving  and  using  digital  information,  and  (3)  digital 
information  must  be  easily  exchanged  between  government  and  industry.  EDI  and  STEP  play  an 
important  role,  since  they  promote  an  end-to-end  transfer  of  all  information,  both  business  and 
technical  data,  for  the  acquisition  and  support  of  DoD  weapon  systems. 

4.2.2  Concurrent  Engineering 

The  traditional  eirgineering  life  cycle  has  four  major  phases  used  in  serial  fashion.  These 
four  phases  are:  requirements  analysis,  design,  manufacture,  and  maintenance  support.  This 
traditional  engineering  life  cycle  has  many  shortcomings  which  results  in  long  times  and  high 
costs  in  introducing  a  new  product. 

Concurrent  engineering  is  a  systematic  ^proach  to  the  integrated  design  of  products  and 
processes,  taking  into  account  concurrently  all  phases  including  requirements  analysis,  design, 
manufacture,  and  maintenance  support.  A  product  is  engineered  by  concurrently  considering  all 
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phases  of  its  life  cycle  and  modifying  the  design  to  optimize  its  suitability  for  all  of  the  phases. 
For  example,  a  product's  maintenance  requirements  are  determined  while  the  product  is  still  being 
analyzed  and  designed;  design  modifications  are  made  to  eliminate  maintenance  problems. 
Concurrent  engineering  is  seen  as  the  key  to  reducing  product  development  cost  by  reducing 
product  reworks  and  modifications  after  a  design  is  released.  Concurrent  engineering  allows  more 
design  changes  than  traditional  processes;  it  concentrates  them  into  the  design  phase  where  design 
changes  are  least  costly.  Concurrent  engineering  also  reduces  both  time  to  market  and  cost,  while 
also  improving  product  quality. 

Figure  4  compares  a  sequential  approach  to  product  development  (at  the  top  of  the  figure) 
with  a  concurrent  approach  (in  the  lower  half).  In  the  sequential  method,  information  flows  from 
left  to  right  only.  In  the  concurrent  approach,  information  flows  are  bi-directional  and  decisions 
are  based  on  consideration  of  downstream  as  well  as  upstream  inputs. 


SaquMitlal  Enghmring 


Analyaic 

OMign 

— 

Production 

Support 

Cencumnt  Engln««rtng 


The  major  obstacles  to  concurrent  engineering  are  the  challenges  posed  by  effectively 
sharing  product  data  across  the  development  phases.  The  foundation  of  effective  concurrent 
engineering  is  a  single  integrated  product  data  base,  such  as  IPDB/IWSDB,  which  stores  all 
product  information  required  by  the  different  life-cycle  phases  and  also  is  easily  accessible  at 
each  phase.  For  convenience  and  efficiency,  the  information  representation  must  also  be  neutral 
with  respect  to  the  different  life-cycle  applications.  STEP  is  designed  to  support  such  an 
application  of  an  integrated  product  data  base  for  concurrent  engineering. 
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4.2.3  Electronic  Data  Interchange 


To  facilitate  the  exchange  of  business  information  in  the  global  marketplace,  national  and 
international  organizations  recognized  the  need  to  standardize  Electronic  Data  Interchange  (EDI) 
message  formats.  In  the  United  States,  the  ANSI  Accredited  Standards  Committee  XI 2  has 
developed  standard  definitions  for  the  components  of  an  EDI  message.  Ho\vever,  the  syntax 
standard  adopted  by  the  EDIFACT  (Electronic  Data  Interchange  for  Administration,  Commerce, 
and  Transport)  is  not  identical  to  XI 2.  As  a  result,  the  EDI  message  developed  by  EDIFACT  are 
not  interchangeable  with  XI 2  messages.  Global  users  will  have  to  support  both  the  ANSI  XI 2 
and  EDIFACT  standards  until  they  can  be  reconciled. 

EDI  is  the  application-to-application  electronic  exchange  of  business  data  in  a 
standardized,  nonproprietary  format.  EDI  replaces  paper  documents  with  an  electronic 
transmission  of  the  data  contained  in  them.  EDI  transmissions  are  machine-readable  and 
transaction-oriented.  They  are  intended  to  be  integrated  into  applications  to  automatically  update 
inventory,  trigger  a  tickler,  invoice  a  customer,  or  pay  a  vendor.  EDI  is  not  the  same  as  an 
exchange  of  forms.  With  EDI,  only  a  document's  contents  are  transmitted,  not  an  image  of  the 
document  itself.  However,  data  can  be  transmitted  via  EDI  to  a  user's  data  base  and  then 
selectively  loaded  into  a  form  displayed  on  the  user's  screen. 

EDI  can  be  viewed  as  an  extended  enterprising  model  that  transcends  the  boundaries  of 
the  organization,  creating  so-called  "virtual  organizations."  EDI  allows  business  partners  to  share 
structured  information.  In  an  extended  enterprising  model,  workflow  progresses  across 
organizational  boundaries.  Government  agencies  and  vendors  not  only  share  the  same 
information  base,  but  also  can  initiate  transactions  across  that  information  base.  EDI,  together 
with  STEP  (for  exchanging  product  data),  plays  a  major  role  creating  a  set  of  operational 
standards  that  influent  CALS  operations. 

CALS  is  gaining  acceptance  around  the  world.  Both  CALS  and  EDI/STEP 
(business/product  data)  are  contributing  to  international  competitiveness  in  a  real  way.  An 
organization's  technology  investments  can  provide  a  gateway  to  the  global  marketplace  if  CALS 
and  EDI^TEP  standards  are  included. 
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4.2.4  Integrated  Logistic  Support 


Integrated  Logistic  Support  (ILS)  is  the  process  through  which  the  composite  of 
nuuiagement  and  analysis  actions  necessary  to  assure  effective  and  economical  support  of  a 
materiel  system,  both  before  and  after  fielding,  are  accomplished.  The  basic  management 
principle  of  the  ILS  process  is  that  logistic  support  resources  must  be  developed,  acquired,  tested, 
and  deployed  as  an  integral  part  of  the  materiel  acquisition  process. 

The  primary  tool  employed  in  ILS  is  the  Logistic  Support  Analysis  (LSA).  For  details  of 
LSA,  please  refer  to  Ref.  1 .  LSA  is  used  to  obtain  a  reliable,  maintainable,  transportable,  and 
supportable  materiel  system  at  the  least  cost  of  ownership  by  integrating  logistic  support 
considerations  into  both  the  system  and  detail  design  efforts. 

The  Logistic  Support  Analysis  Record  (LSAR)  is  a  system  of  data  records,  computer 
programs,  and  output  reports  which  has  been  developed  to  document  portions  of  the  LSA.  The 
LSAR  provides  a  single  logistic  data  base  to  input,  store,  process,  and  retrieve  selected  LSA  data. 
For  details  of  LSAR,  see  Ref.  2. 

4.2.5  Relationship  Between  CE  and  ILS 

The  CALS  acceleration  of  information  distribution  and  delivery  will  materially  enhance 
the  efficiency  of  CE  processes.  A  prerequisite  for  CE  and  ILS  is  an  efficient  information  flow  by 
means  of  an  electronic  data  interchange  closely  combined  with  IPDB/IWSDB  for  storage  and 
retrieval  of  these  product  data.  Therefore,  a  worldwide  standardized  EDI  is  required  not  only  for 
develqiinent,  design,  and  manufacturing  data,but  also  for  product  support;  program  management; 
and  operational  business  information.  In  this  scenario,  the  CALS  strategy  can  be  regarded  as  an 
umbrella  for  all  relevant  standards  requited  for  die  EDI  of  CE  and  ILS.  Figure  5  (from  Ref.  52) 
shows  these  relationships. 
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Fig.  5.  Intemlationship  of  CE  and  ILS. 


4.2.6  LSAR,  Provisioning  and  TM  Integration 

Currently,  there  is  data  duplication  and  overlap  in  the  LSAR,  TM  (including 
maintenance,  training,  etc.),  and  provisioning  data  bases.  Shared  information  is  not  prepared  once 
and  then  utilized  throughout  each  area  of  a  weapon  system  program.  In  many  cases,  the 
organizational  structure  determines  how  the  LSAR,  TM,  and  part  provisioning  data  are  procured 
and  developed.  As  a  result,  work  is  performed  along  traditional  organizational  lines,  with  little 
consideration  of  the  concurrent  engineering  principle.  Therefore,  costs  for  developing  and 
updating  the  various  data  bases  for  LSAR,  TM,  and  parts  provisioning  are  high  due  to  the 
duplication  of  effort.  Duplication  could  also  result  in  errors  and  inconsistencies  in  the  same 
infomoation  in  the  different  data  bases.  Development  of  the  LSAR,  TM,  and  parts  provisioning 
data  should  be  oriented  to  shared  data  element  generation  and  should  not  be  oriented  to  product 
develqrment.  Reference  59  estiituUes  that  development  costs  can  be  reduced  25  percent  through  a 
shared  data  base  for  LSAR,  and  TM. 

4.3  STandard  for  the  Exchange  of  Product  Model  Data 

STandard  for  the  Exchange  of  Product  (STEP)  rtKxlel  data  is  the  unofficial  name  for  the 
ISO  10303  standard  being  developed  by  the  International  Organization  for  Standardization  (ISO). 
STEP  is  fcmnally  called  the  "Industrial  Automation  Systems  and  Integration  -  Product  Data 
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Representation  and  Exchange  Standard."  In  the  United  States,  STEP  is  known  as  PDES  (Product 
Data  Exchange  using  STEP),  the  U.S.  organizational  activity  which  supports  the  development  and 
implementation  of  STEP.  Product  data  is  defined  as  the  data  used  to  define  the  product  over  its 
life  cycle;  the  data  include  geometry,  tolerance,  material  composition,  assembly  information,  and 
other  attributes  necessary  to  completely  define  a  component  for  design,  analysis,  manufacture, 
test,  inspection,  support,  maintenance,  and  disposal. 

STEP  is  an  international  standard  which  is  being  designed  to  give  a  complete  computer- 
interpretable  representation  of  product  data  in  a  neutral  format  throughout  the  complete  product 
life-cycle  (design,  engineering  analysis,  manufacture,  support  and  maintenance,  and  disposal).  As 
a  result,  STEP  is  suitable  not  only  for  file  exchange  but  also  for  serving  as  the  basis  for 
implementation,  sharing,  and  archiving  product  data  bases. 

The  STEP  standard  is  fundamental  to  the  CALS.  CALS  encompasses  an  architecture  for 
Contractor  Integrated  Technical  Information  Services  (CmS)  which  requires  an  IPDB/IWSDB. 
The  STEP  shared  data  environment  will  provide  the  kernel  of  the  IPDB/IWSDB  and  will  support 
information  access  for  prime  contractors,  sub-contractors,  and  the  DoD. 

4.3.1  Application  Protocols 

Application  Protocols  (APs)  provide  the  mechanism  both  for  specifying  implementation 
requirements  and  for  ensuring  reliable  information  conununication  within  the  context  of  a  given 
qipUcation.  An  AP  is  a  complete  specification  of  the  context  and  scope  for  the  use  of  product 
data  in  a  particular  domain  using  standardized  integrated  resources  and  other  application  specific 
entities.  The  AP  also  describes  the  conformance  requirements.  Appendixes  C  and  D  list  APs 
currently  being  developed  within  the  ISO  STEP  community. 

4.3.2  Conq)onents  of  Application  Protocol 

Figure  6  shows  the  steps  and  components  in  the  development  of  an  AP: 


15 


SSQE£ 

What  tunehon»7 

WhatpnxhKt 

tjfpaa? 

WlmtkkK^  ot 

tollman 

ayatama? 

dotnaadtodo 

UXFO 

my  job? 

tOEFIX 

NIAM 

Homdol 
lapnaant  thia 

ConlOrmanca 

Raaulrammnia 

Laganda; 

JnftMiMtlon 

mUhSTEP? 

EXPPESS 

WhatwIUllaat 

tor? 

•  Acnmy  moaamg  mot 

Abatraet  Taat 

BSeFIK  MAM  -  Data  modaOng  toola 

Expnaa  •  DMa  Me 

dadng  and  STBP  In 

tagradon  tool 

Fig.  6.  Stap*  In  tlw  davalopmant  of  an  appUeaMon  protocol. 


a.  Application  Activity  Model: 

The  scope  statement  is  based  on  an  Application  Activity  Model  (AAM)  developed  by  the 
Integrated  Computer-aided  Manufacturing  Definition  Method  (IDEFO).  The  AAM  is  used  to 
clarify  the  application  activities,  processes,  and  data  flows  involved  in  the  application. 

b.  Application  Reference  Model: 

The  Application  Reference  Model  (ARM),  describes  the  information  requirements, 
content,  structure,  and  constraints  with  regard  to  the  specific  application  domain.  The  ARM  is 
develq)ed  in  one  of  the  following  modeling  languages:  EXPRESS,  the  Integrated  Computer- 
aided  Manufacturing  Defmition  Method  (IDEFIX),  or  Nijssen's  Information  Analysis 
Methodology  (NIAM). 

c.  Application  Interpreted  Model: 

An  ^iplication  interpreted  Model  (AIM)  is  developed  by  interpreting  the  Integrated 
Resource  (Constructs  (IRC)  and  Application  Interpreted  Constructs  (AIC)  based  on  the 
information  requirements  defined  in  the  ARM.  The  AIM  is  defmed  using  the  EXPRESS 
language. 

When  two  or  more  APs  contain  equivalent  information  requirements,  these  APs  shall  use 
die  same  inteipietation  of  the  IRCs.  A  group  of  constructs  which  comprise  a  common 
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interpretation  of  common  information  requirements  is  called  an  AIC.  A  library  of  these  AICs 
(Fig.  7)  shall  be  maintained  as  a  resource  for  defining  AIMs. 

AppUemtfon 
Modal  (ARM) 

AppUcaUon 
IntoipnMd 
MotM(AIM) 


Intorpntad 
CoiMnict  (K) 
or  Intogratod 
Raooureoo  (IRa) 

d.  Conformance  Requirements  and  Test  Purposes: 

The  AP  also  includes  a  set  of  conformance  requirements  and  test  procedures  from  which 
an  abstract  test  suite  may  be  developed  and  used  for  conformance  testing. 

4.3.3  Application  Protocol  Inqilementation 

STEP  provides  a  wide  variety  of  levels  for  system  implementation.  Implementation  levels 
are  particular  ways  of  storing,  exchanging,or  accessing  information  which  is  distinguished  by  the 
degree  of  data  sharing.  Those  levels  may  include  the  following: 

a.  Exchange  File  •  Product  data  are  exchanged  between  computer  systems  or 
appUcations  using  STEP  exchange  files  which  are  defined  in  STEP  Part  21  (see  Appendix  C). 

The  structure  of  the  exchange  file  is  derived  from  the  conceptual  data  model's  EXPRESS 
definition  (AIM).  It  is  expected  that  the  early  use  of  STEP  will  involve  using  exchange  files  to 
move  data  between  systems. 

b.  Data  base  -  Product  data  are  stored  and  accessed  in  data  bases  based  on  various  data 
base  architectures  (such  as  relational  or  object-oriented).  This  data  base  level  will  allow 
applicatitm  developers  to  create,  manipulate,  and  share  STEP  data,  based  on  standard  data  nuxiels 
and  system  intnfaces.  Applications  use  a  standard  query  language  such  as  SQL  or  standard 
interfaces  such  as  the  STEP  Data  Access  Interface  (SDAI)  defined  in  Part  22  (see  Appendix  D). 


Inlagratad  Raaourea  ContnieM  ^C)  and 
AppdeaUon  Intarpralad  Contueta  (AIC) 

- 


Fig.  7.  Development  of  AIMS. 
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c.  Data  Access  -  Product  data  can  be  accessed  independent  of  the  storage  method  used. 

As  STEP  evolves,  it  will  provide  a  major  portion  of  the  functional  framework  for  the 
IPDB/IWSDB.  Due  to  the  rapid  international  acceptance  of  the  CALS  initiative  and  the 
worldwide  agreement  that  STEP  can  be  the  future  standard  for  product  data  exchange,  a  world¬ 
wide  standard  on  product  data  can  be  built  from  the  beginning  -  a  tme  breakthrough  in  the  CALS 
standards  world.  STEP  and  the  development  of  the  IPDB/IWSDB  are  the  most  technically 
challenging  CALS  responsibilities. 

4.3.4  Application  Protocol  Interoperability 

More  than  forty  APs  (Appendixes  C  and  D)  have  been  approved  by  ISO  TCI  84/SC4  for 
formal  development  as  part  of  the  STEP  standards.  The  implementation  of  these  APs  will  provide 
the  solution  for  product  data  exchange.  AP  interoperability  implies  that  two  APs  will  be  able  to 
share  data  which  is  defined  in  the  overlapping  area  of  the  APs.  The  development  of  the  Integrated 
Resources  (IRs)  (see  Fig.  7)  that  support  the  information  requirements  of  multiple  applications 
ensures  the  interoperability  of  APs.  Therefore,  two  or  more  APs  can  exchange  data  only  if  they 
share  common  IRs. 

4.3.5  Impact  of  STEP 

STEP  is  an  extremely  broad  specification,  including  virtually  every  data  item  required  to 
develop,  analyze,  manufacture,  document,  and  support  products  ranging  from  mechanical 
products  and  electronic  products,  to  large  structures  such  as  ships  and  buildings. 

STEP  is  a  conceptual  specification  for  communicating  product  information  at  all  stages  in 
a  product's  life  cycle,  covering  all  aspects  of  product  description  and  manufacturing 
specifications.  The  fundamental  components  of  STEP  are  the  product  information  models  and 
specifications  to  exchange  information  corresponding  to  these  product  models. 

STEP  will  provide  tools  to  reduce  time  to  market,  lower  costs,  improve  quality,  and 
continuously  mq>rove  processes.  STEP  will  enable  the  effective  integration  of  finance,  nuuketing, 
engineering,  manufacturing,  and  support  data.  STEP  data  are  open,  are  independent  of  the 
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applications  or  systems  that  create  it.  and  are  accessible  to  and  usable  by  any  other  applications 
that  need  to  use  them.  STEP  will  provide  the  ability  to  turn  data  into  meaningful  information  to 
support  decision  making,  and  will  provide  a  foundation  for  the  next  generation  of  open  systems. 

4.4  Pilot  PLS  APs  Implementation  Requirements 

The  first  step  in  the  implementation  of  the  pilot  PLS  APs  was  to  define  the  scope  and 
requirements  for  both  military  and  industrial  use  in  the  product  logistic  support  area. 

In  cooperation  with  the  CALS/CE ISG  (Industry  Steering  Group)  SALSA  (Spares 
Acquisition  and  Logistics  Support  Analysis)  Committee  and  other  representatives  from  European 
countries,  the  draft  of  the  pilot  PLS  APs  implementation  requirements  has  been  completed;  see 
Appendixes  A  through  I.  Two  working  group  meetings  were  held  on  2  September  1994  (third 
quarter  SALSA  committee  meeting)  and  2  November  1994  (fourth  quarter  SALSA  committee 
meeting  at  CALS  Expo  93)  respectively.  Assistance  was  also  obtained  from  the  Air  Force’s 
ManTech  office  which  initiated  and  managed  the  STEP  AP-209  and  AP-21 1  contracts.  The 
highlights  of  the  implementation  requirements  are  as  follows: 

a.  The  pilot  PLS  APs  is  designed  as  part  of  the  ISO  STEP  standards  for:  (1)  establishing 
the  information  requirements  to  ensure  reliable,  maintainable,  and  supportable  products  at 
minimum  life-cycle  cost,  and  (2)  representing  and  exchanging  product  logistic  support 
information  by  the  implementation  of  a  common  and  shared  integrated  information  environment 
for  LSAR,  TM,  parts  provisioning,  and  order  administration. 

b.  The  development  of  the  pilot  PLS  APs  primarily  will  be  based  on  the  harmonization 
of  existing  European  AECMA  specifications,  U.S.  CALS  standards,  and  other  national  and 
international  standards  in  the  acquisition  logistic  area.  This  will  be  accomplished  by  drawing 
upon  the  efforts  that  are  being  performed  by  CALS,  AE(2MA,  ANSI,  ATA/AIA,  and  ISO 
standards.  These  standards  and  specifications  include: 

MIL-STD-1388-2B:  LSAR  (Logistic  Support  Analysis  Record) 

MIL-M-28001:  SGML  (Standard  General  Markup  Language) 

MIL-D-87269:  lETMDB  (Interactive  Electronic  Technical  Manual) 

MILSTRIP:  Military  Standard  Requisitioning  and  Issue  Procedures 


MILSTRAP;  Military  Standard  Transaction  Reporting  and  Accounting  Procedures 

AECMA  Spec  2000M;  Material  Provisioning  and  Management 

AECMA  Spec  lOOOD:  Technical  Publication 

ATA  Spec  100:  Manufacturers  Technical  Data 

ATA  Spec  200:  Data  Base  and  Customer  Support 

ISO  8879:  SGML  (Standard  Generalized  Markup  Language) 

ISO  10744:  HyTime  (Hypermedia/Time-based  Structuring  Language) 

c.  Some  of  the  standards  on  which  this  standard  will  be  based  such  as  AECMA  lOOOD 
and  2000M  are  developed  specifically  for  air  vehicles  acquisition  and  support  (e.g.,  the  Standard 
Numbering  System  and  Data  Module  Code  of  AECMA  lOOOD),  this  pilot  PLS  APs  prototyping 
effort  (which  can  be  implemented  in  about  three  years)  also  will  focus  on  air  vehicles.  After  the 
completion  of  and  the  assimilation  of  lessons  learned  from  this  pilot  development  effort,  the 
scope  of  the  pilot  PLS  APs  can  be  expanded  to  include  land  and  sea  vehicles  as  well  as  other 
product  areas  at  a  later  time. 

d.  This  pilot  PLS  APs  will  meet  requirements  and  also  will  prove  useful  and  effective  for 
both  military  and  industrial  operations. 

e.  This  pilot  PLS  APs  will  accept  the  NATO  standards  harmonization  workshop 
recommendations  (see  Appendix  G). 

f.  This  pilot  PLS  APs  will  ensure  compatibility  with  the  planned  TDP  (Technical  DtUa 
Package)  and  PSA  (Product  Support  Analysis)  APs  (see  Appendix  H). 

Figure  8  (see  Appendix  E)  is  the  currently  envisioned  configuration  implementation.  The 
actual  configuration  implementation  can  vary ,  if  detailed  analysis  warrants.  It  assumes  that  the 
pilot  PLS  APs  (Box  2  of  Hg.  8)  includes  three  STEP  APs  (Boxes  3, 4,  and  S).  A  more  detailed 
description  of  Fig.  8  can  be  found  in  Appendix  F  of  this  report. 

4.5  Resources  Estimates 

The  resources  required  to  complete  the  initial  implementation  of  the  pilot  PLS  APs  for  air 
vehicles  are  estimated  to  be  about  ten  full-time  equivalents  per  year  for  the  first  two  years  and 
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about  four  full-time  equivalents  for  the  third  year.  All  countries  participating  in  the  pilot  PLS 
APs'  development  will  be  requested  to  share  the  development  costs. 

4.6  Implementation  Strategy 

The  strategy  for  the  implementation  of  pilot  PLS  APs  is  as  follows. 

a.  Due  to  the  excessive  labor  required  to  implement  the  pilot  PLS  APs.  the 
implementation  requirements  wi’’  be  developed  as  a  SOW  and  then  a  cost  plus  type  of  contract 
will  be  awarded  to  a  qualified  company  for  ihe  development  of  this  pilot  PLS  APs.  Because  this 
pilot  PLS  APs  will  be  an  ISO  international  standard,  the  requirements  will  be  defined  by  multi¬ 
national  representatives  and  used  by  different  countries  for  the  exchange  of  product  logistic 
support  data.  All  participating  countries  will  be  requested  to  share  developmental  funding. 

b.  The  Program  Management  Board  (PMB)  will  consistof  representatives  from  fund- 
contributing  countries  to  manage  this  contract.  The  Industry  Review  Board  (IRB)  will  be  formed 
from  the  CALS  ISG,  NATO  lAG  (Industry  Advisory  Group),  and  other  CALS  advisory  groups  of 
the  participating  countries  to  provide  advice  to  the  pilot  PLS  APs  development  team.  The  IRB 
will  provide  a  forum  for  international  industry  to  review  the  progress  of  this  effort  and  to  offer 
advice  and  guidance  to  the  pilot  PLS  APs  development  team.  The  IRB  makeup  shall  be 
determined  by  both  the  PMB  and  the  contractor.  IRB  comments  and  reconunendations  resulting 
from  review  meetings  shall  be  considered,  and  acted  upon  when  the  PMB  deems  them 
appropriate. 

c.  The  PMB  will  continue  to  work  with  IRB  to  completely  define  the  SOW  (see 
Appendix  E),  develop  the  RFP,  and  award  the  contract  in  1995.  The  contractor  shall  complete  the 
development  of  the  pilot  PLS  APs  in  three  years. 

d.  The  development  effort  will  be  managed  using  a  multi-phase  ^proach  to  incremen¬ 
tally  develop  the  pilot  PLS  APs.  There  will  be  three  major  phases  which  are  described  in  mote 
detail  in  Section  4.7.  The  rationale  in  developing  the  pilot  PLS  APs  in  a  phased  tq)proach  is  to 
minimize  the  risks  associated  with  atten^)ting  to  develop  the  conq>lete  suite  as  a  single  effort. 
Each  incremental  phase  addition  to  the  suite  builds  upon  the  foundation  provided  by  earlier 
efforts. 
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e.  Methods  will  be  developed  to  ensure  that  the  APs  development  meets  ISO  STEP  AP 
requirements. 

f.  The  PMB  will  ensure  that  the  contractor  shall  plan  for  the  transfer  of  the  technology 
established  in  this  program  to  industry  and  to  the  government  of  all  participating  countries.  The 
contractor  shall  identify  the  anticipated  requirements  for  and  the  benefits  of  implementing  this  AP 
suite. 


4.7  Implementation  Phases 

The  development  of  the  pilot  PLS  APs  consists  of  two  development  phases  and  one 
demonstration  phase. 

Phase  I  -  Technical  Issues  Assessment  and  Pilot  PLS  APs  Development  and 

Demonstration  Planning 

The  technical  issues  crucial  to  the  pilot  PLS  APs  development  effort  should  be 
thoroughly  analyzed  and  studied  first .  All  of  the  identified  technical  issues  are  described  in 
Section  S  of  this  report.  All  of  the  proposed  technical  solutions  should  be  presented  to  and  agreed 
upon  by  the  IRB  and  then  iqiproved  by  the  PMB  before  proceeding  to  Phase  n  of  this  contract. 
The  technical  issues  should  include  the  following  agenda: 

a.  Establish  the  functional  view  (IDEFO)  of  the  pilot  PLS  APs.  Develop  integratable  and 
harmonized  data  models  (IDEFIX)  for  each  of  the  APs  (see  Fig.  8)  included  in  the  pilot  PLS  APs. 

b.  Develop  a  data  element  dictionary  for  the  data  models.  Assess  the  technical  issues  and 
determine  any  risks  involved. 

c.  Prepare  a  plan  to  develop  and  demonstrate  the  pilot  PLS  APs  with  respect  to  a 
risk/benefits  analysis  and  technical  issues  assessment. 

d.  Provide  a  plan  for  the  development  and  demonstration  of  the  AP  suite  to  be  used  in 
Phases  II  and  EQ  respectively. 
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e.  Analyze  the  issues  and  problems  for  the  integration  and  harmonization  of  the 
standards  involved. 

f.  Assess  and  evaluate  current  STEP  content  and  scope  to  determine  the  STEP  capability 
to  support  the  development  of  this  AP  suite.  This  assessment  should  project  the  progress  of  the 
STEP  planned  activities  and  emerging  technologies  that  appear  to  offer  contribution  and  impact 
to  this  program  and  to  identify  the  inadequacies  where  the  pilot  PLS  APs  needs  are  not  supported 
by  STEP. 

g.  Produce  an  APs  development  and  demonstration  strategy.  Develop  a  set  of  criteria 
with  which  the  potential  costs  and  benefits  can  be  measured  in  relation  to  the  NATO  requirements 
to  utilize  the  pilot  PLS  APs.  The  program  shall  not  proceed  with  Phase  n  without  the  successful 
completion  of  Phase  I. 

Phase  n  -  Pilot  PLS  APs  Development 

Phase  n  shall  provide  the  development  and  specification  of  required  models,  mappings, 
and  test  criteria  needed  to  support  the  functionality  resulting  from  Phase  I. 

The  pilot  PLS  APs  is  developed  using  the  Application  Reference  Model(s)  (ARMs), 
Application  Interpreted  Model(s)  (AIMs),  and  conformance  and  test  criteria  (CTC).  The  process 
is  to  identify  enhancements  and  proposed  improvements  for  the  STEP  Community;  refine 
preliminary  activities  to  provide  a  detailed  and  cost  effective  demonstration  plan;  coordinate  the 
development  of  the  AP  suite  with  international  industry  and  standards  organizations  to  facilitate 
the  harmonization  of  data  standards;  and  submit  the  ARMs,  AIMs,  CTC,  and  other  necessary 
documents  to  the  ISO  STEP  organization  in  order  to  qualify  the  pilot  PLS  APs  as  ISO 
standard(s). 

Phase  in  -  Pilot  PLS  APs  Demonstration 

Phase  m  shall  provide  the  demonstration  and  validation  of  the  application  protocol  suite 
developed  in  Phase  II 
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Phase  ni  will  demonstrate  functionality  of  the  pilot  PLS  A**s.  Tasks  are  to;  (1)  project  the 
performance  and  analyze  the  potential  benefits  accruing  from  implementing  the  AP  suite  in 
working  environments;  and  (2)  debrief  industry  and  government  representatives  on  the  results  and 
potential  impact  of  this  program.  The  contractor  shall  plan  for  the  transfer  of  the  technology 
developed  by  this  program  to  industry. 


5.0  TECHNICAL  ISSUES 


.  In  the  development  of  the  pilot  PLS  APs,  there  are  many  technical  issues  that  need  to  be 
understood,  analyzed,  agreed  upon,  and  resolved.  Phase  I  of  this  pilot  PLS  APs  development 
effort  will  be  totally  devoted  to  the  analysis  and  resolution  of  the  technical  issues.  The  results 
from  the  execution  of  Phase  I  will  have  to  be  completely  satisfactory  before  the  starting  of 
Phase  n.  The  technical  issues  cmcial  to  the  pilot  PLS  APs  development  include  the  following, 
detailed  description  of  the  technical  issues  that  can  be  found  in  Appendix  F  of  this  report. 

a.  Data  Modeling  and  Data  Model  Integration 

Conceptual  data  modeling  is  becoming  one  of  the  most  powerful  techniques  for 
establishing  and  maintaining  control  over  information  resources.  Data  models  are  used  to 
represent  conceptual  schemes  and  to  help  integrate  the  information  resources.  Integrating  large 
data  resources  without  using  data  models  can  be  very  difficult.  'Die  challenge  in  developing  this 
pilot  PLS  APs  is  the  development  of  integratable  data  models  based  on  the  existing  data  standards 
and  specifications  which,  in  most  cases,  are  not  compatible  with  each  other. 

b.  Enhancement  of  MIL-STD- 1388 

The  NATO  Haimonization  Assessment  Woritshop  in  Acquisition  Logistics  Standards 
(see  Ref.  51)  and  the  ATIS  (Advanced  Technical  Information  System)  program  reconunended 
that  the  scope  of  MIL-STD- 1388  be  expanded  to  include  the  following  functions.  The 
introduction  of  these  processes  may  require  additional  data  elements. 
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c.  Integration  Key 


The  activities  of  engineering  design,  LSA,  technical  documentation,  and  initial 
provisioning  need  a  mechanism  to  provide  an  integrated  cross  reference  capability.  A  single 
integration  key  is  needed  to  cross  reference  each  technical  subject  area. 

This  approach  does  not  require  the  development  of  any  new  data  elements,  but  uses  a 
management  activity  to  align  and  normalize  the  data  between  functional  activities.  Other 
technical  disciplines  can  be  added  to  the  table  without  changing  the  existing  structure  or  any 
existing  relationships. 

d.  Integration  of  the  PSA  and  ETM  APs 

The  benefits  of  integrating  the  LSAR  with  ETM  data  bases  are  well  known  (see  Refs.  56 
to  59).  Some  companies  have  experienced  a  cost  reduction  of  more  than  25  percent  in  ETM 
authoring  by  integrating  the  LSAR  and  ETM  data  bases  to  improve  the  LSAR  and  ETM 
authoring  processes. 

The  PSA  and  ETM  data  models  should  become  the  major  components  of  both  the  CALS 
IPDB/IWSDB  and  AECMA  CSDB. 

e.  Integration  of  AECMA  I(X)OD  and  MIL-D-87269  (lETMDB) 

Each  of  these  two  specifications  contains  a  DTD  (Document  Type  Definition)  based  on 
the  same  ISO  8879  (SGML)  specification  for  a  neutral  data  base.  However,  these  two  DTDs  are 
different  as  they  are  designed  for  different  technical  documentation  structures.  The  AECMA 
lOOOD  has  been  designed  with  the  guideline  to  use  MIL-M-28001  as  close  as  possible.  For  ETM 
and  lETM  within  AECMA  lOOOD  the  MIL-D-87269  is  used  as  a  basic  reference  document. 
Incompatibilities  will  be  reported. 

f.  DTDs  for  the  Training  Material 

The  costs  of  providing  separate  hardware  and  software  systems  for  ETMs,  computer- 
aided  training  (CAT)  ^  automatic/electronic  test  (ATE)  equipment  are  high.  In  many  instances. 
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space  is  not  available  for  separate  systems.  A  set  of  SGML  generic  data  element  stmctures  and 
DTDs  for  training  material  should  be  developed. 


g.  Integration  of  AECMA  20(X)M  and  M1L-STD-1388-2B 

MIL-STD-1388-2B  (LSAR)  and  AECMA  2000M  are  mutually  complementary  in  scope 
and  focus.  Since  LSAR  collects  its  data  as  part  of  the  system  engineering  management  process, 
the  resultant  LSAR  data  base  could  conceivably  provide  the  separable  item  data  required  by 
AECMA  2000M  for  the  Initial  Provisioning  Lists  (IPL)  and  Illustrated  Parts  Catalogues  (IPC) 
construction. 

h.  Integration  of  AECMA  2000M  and  MILSTRIP/MILSTRAP 

The  functionality  of  MIL-STRIP/STRAP  (Refs.  7  and  8)  overlaps  that  of  AECMA 
2000M  to  a  great  extent.  Except  for  stock  replenishment  modeling,  both  standards  control  the 
material  flow/demand  between  a  contractor  and  a  customer.  By  redefining  the  roles  of  and  the 
related  data  for  customer  and  contractor  on  an  operative  functional  level,  both  standards  can  be 
harmonized. 

i.  Data  Dictionary 

After  the  various  data  models  (Fig.  8,  Boxes  3, 4,  and  5)  have  been  developed  and 
integrated,  a  consistent  data  element  dictionary  which  encompasses  all  the  data  models  will  be  a 
natural  output.  DoD  8320.1-M-l  (Ref.  IS)  should  be  regarded  as  the  guiding  document  for  the 
development  of  this  dictionary. 


6.0  BENEFITS  ASSESSMENT 


The  STEP  pilot  PLS  APs  is  primarily  based  on  the  integration  of  two  key  CALS 
standards,  M1L-STD-1388-2B  and  MIL-D-87269.  A  25  percent  savings  in  TM  authoring  has 
beat  realized  (see  Ref.  59)  in  the  integration  of  LSAR  (MIL-STD-1388-2A)  and  TM  data  bases. 
This  pilot  PLS  APs  effort  will  accelerate  the  integration  of  the  TM  and  LSAR  data  bases. 
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The  STEP  pilot  PLS  APs  will  harmonize  the  U.S.  CALS  standards  with  the  European 
NATO  AECMA  specifications.  This  will  greatly  facilitate  the  exchange  of  logistic  and 
maintenance  information  among  the  NATO  countries,  and  also  will  establish  a  common 
international  basis  for  the  data  exchange  of  logistic  and  maintenance  information. 

Active  U.S.  participation  would  ensure  that  U.S.  military  and  industry  requirements  be 
addressed  in  the  pilot  PLS  APs.  Lack  of  U.S.  involvement  could  allow  the  adoption  of  non-U.S. 
requirements  in  the  pilot  PLS  APs  development.  This  would  result  in  less-compatible 
requirements  for  the  U.S.  industry  and  consequently  higher  conversion  costs  for  U.S.  industries. 
The  MIL-STD-1388-2B  standard  has  large  implementation  bases  in  this  country.  This  would 
favor  U.S.  industry  in  the  world  market  competition.  Adoption  of  U.S.  military  standards  would 
enhance  foreign  military  sales.  The  Navy  has  been  active  in  STEP  development  since  1987 
through  NIDDESC  (Navy  Industry  Digital  Exchange  Standards  Committee)  and  RAMP  (Rapid 
Acquisition  Manufacturing  Parts)/FCIM  (Flexible  Computer  Integrated  Manufacturing). 


7.0  CONCLUSIONS  AND  RECOMMENDATIONS 


This  report  documents  woric  performed  in  FY-93  and  94  concerning  the  identification  and 
definition  of  the  requirements  for  the  implementation  of  PLS  APs.  Due  to  the  very  limited 
funding  (less  than  a  man-year)  available,  a  draft  SOW  for  PLS  APs  was  developed  (Appendixes 
A  through  I)  with  the  help  of  the  CALS/CE ISG  SALSA  technical  committee. 

For  future  work,  it  is  recommended  that  an  international  working  committee  in  the  area  of 
product  logistic  support  be  formed  to  complete  the  development  of  this  SOW  and  then  to  manage 
the  implementation  of  these  PLS  APs. 
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APPENDIX  A  -  GLOSSARY 


AAM  -  Application  Activity  Model 

AECMA  -  Association  Europeene  des  Constructeurs  de  Materiel  Aerospatial 
AIA  -  Aerospace  Industries  Association 
AIC  -  Application  Interpreted  Construct 
AIM  -  Application  Interpreted  Model 

ALC  -  Alternate  Logistic  Support  Analysis  Control  Number  Code 

AP  -  Application  Protocol 

ARM  -  Application  Reference  Model 

ATA  -  Air  Transport  Association 

AXIS  -  Advanced  Technical  Information  System  (Air  Force  B-2  Program) 

CAD  -  Computer  Aided  Design 

CAE  -  Computer  Aided  Engineering 

CALS  -  Continuous  Acquisition  and  Life-cycle  Support 

CDRL  -  Contract  Data  Requirements  List 

CrilS  •  Contractor  Integrated  Technical  Information  Services 

CLDM  -  Corporate  Logistics  Data  Model  (DoD  JLSC) 

CSDB  -  Common  Source  Data  Base 

CTC  -  Conformance  and  Test  Criteria 

DBMS  -  Data  Base  Management  System 

DED  -  Data  Element  Description 

DLE  -  Defense  Logistics  &icyclopedia  (DoD  JLSC) 

DoD  -  Department  of  Defense 
DTD  -  Document  Type  Definition 
EDI  -  Electnmic  Data  Interchange 

EDIFACT  -  Electronic  Data  Interchange  for  Administration,  Commerce  and 
Transport 
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GLOSSARY  (CONTINUED) 


EFA  -  European  Fighter  Aircraft 

EDFP  -  Engineering  Data  For  Provisioning  (SPTD) 

EPC  •  Electronic  Publishing  Committee 

ETM  -  Electronic  Technical  Manual 

FCIM  -  Flexible  Computer  Integrated  Manufacturing 

FMECA  -  Failure  Modes,  Effects  and  Criticality  Analysis 

FRACAS  -  Failure  Reporting  and  Corrective  Action  System 

FOSI  -  Formatting  Output  Specification 

lAG  -  Industry  Advisory  Group 

IDEF  -  ICAM  (Integrated  Computer-Aided  Manufacturing)  DEFinition  Method 

EETM  -  Interactive  Electronic  Technical  Manual 

lETMDB  -  Interactive  Electronic  Technical  Manual  Data  Base 

IGES  -  Initial  Gr!q)hics  Exchange  Specification 

ILS  -  Integrated  Logistic  Support 

IPC  •  Illustrated  Parts  Catalogues 

IPDB  -  Integrated  Product  Data  Base 

IFL  -  Initial  Provisioning  Lists 

IRB  -  Industry  Review  Board 

IRC  -  Integrated  Resource  Construct 

IRM  -  Integrated  Resources  Model 

ISG  -  Industry  Steering  Group 

ISO  -  International  Organization  for  Standardization 

IWSDB  -  Integrated  Weapon  System  Data  Base 

LC!N  -  Logistic  Control  Number 

LSAR  -  Logistic  Support  Analysis  Rectml 

NATO  -  North  Atlantic  Treaty  Organization 

NIAM  -  Nijssen  Information  Analysis  Model 
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GLOSSARY  (CONTINUED) 


NIDDESC  -  Navy  Industry  Digital  Data  Exchange  Standards  Committee 

OS  -  Output  Specification 

OSD  -  Office  of  Secretary  of  Defense 

PDES  -  Product  Data  Exchange  using  STEP 

PLS  -  Product  Logistic  Support 

PMB  -  Program  Manager  Board 

PSA  -  Product  Support  Analysis 

PTD  -  Provisioning  Technical  Package 

RAMP  -  Rapid  Acquisition  Manufactures  Parts 

RFP  -  Request  for  Proposal 

SDAI  -  STEP  Data  Access  Interface 

SALSA  •  Spares  Acquisition  and  Logistic  Support  Analysis 

SGML  -  Standard  Generalized  Markup  Language 

STEP  -  STandard  for  the  Exchange  of  Product  data  model 

TCP  -  Target  Qqiability 

TDP  -  Technical  Data  Package 

TM  -  Technical  Manual 
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APPENDIX  B  .  REFERENCED  DOCUMENTS 


STANDARDS  AND  SPECfflCATIONS 

1.  MIL-STD- 1388-1 A  "Logistic  Support  Analysis  (LSA)" 

2.  MIL-STD-1388-2B  "Logistic  Support  Analysis  Record  (LSAR)" 

3.  MIL-D-87269  "Data  Base,  Revisable:  Interactive  Electronic  Technical  Manuals,  for  the 

support  of 

4.  MIL-M-28001  (SGML)  "Markup  Requirements  and  Generic  Style  Specification  for  Electronic 

Printed  Output  and  Exchange  of  Text" 

5.  AECMA  SPEC  2000M  "International  Specification  for  Material  Management  Integrated  Data 

Processing  for  Military  Equipment” 

6.  AECMA  SPEC  lOOOD  "International  Specification  for  Technical  Publications  Utilizing  A 

Common  Source  Data  Base" 

7.  MILSTRIP  "Military  Standard  Requisitioning  and  Issue  Procedures" 

8.  MILSTRAP  "Military  Standard  Transaction  Reporting  and  Accounting  Procedures 

9.  Proposed  ISO  STEP  Technical  Data  Package  (TDP)  AP 

10.  Proposed  ISO  STEP  Product  Support  Analysis  (PSA)  AP 

11.  MIL-D-87268  "Manual  Technical:  Genera]  Content,  Style,  Format,  and  User  Requirements 
for  Interactive  Electronic  Technical  Manuals" 

12.  MIL-D-87270  "Quality  Assurance  Program:  Interactive  Electronic  Technical  Manuals  and 
Associated  Technical  Information;  Requirements  for" 

13.  MIL-STD- 1840B  "Automated  Interchange  of  Technical  Information" 

14.  MIL-HDBK-59  "CALS  Program  Implementation  Guide" 

15.  DoD  8320.1-M-l  "Data  Element  Standardization  Procedures" 

16.  ISO  8879  "Standard  Generalized  Mai^up  language" 

17.  MIL-STD-21SS  "Failure  Reporting  and  Corrective  Action  System" 

18.  ISO  10744  "Hypermedia/Time-based  Structuring  Language" 

19.  ISO  DIS  10179  "Document  Style  Semantics  and  Specification  language" 

20.  IMPAES  "Initial  Multimedia  Presentation  and  Access  Exchange  Specification" 
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REFERENCED  DOCUMENTS  (CONTINUED) 


PROGRAMS 

21 .  ljD  Integrated  Computer  Aided  Provisioning  (ICAP)  Program 

22.  DoD  JCALS  program 

23.  U.S.  Air  Force  F-22  Procurement  program 

24.  European  Fighter  Aircraft  (EFA)  Program 

25.  ATA  Spec  2100  "Digital  Data  Standards  for  Aircraft  Support” 

26.  ATA  Spec  100  "Manufacturers  Technical  Data" 

27.  ATA  Spec  2000  "Data  Base  and  customer  Support" 

PROJECTS 

3 1 .  DoD  JLEC  Defense  Lciiistic  Encyclopedia  (DLE) 

32.  DoD  JLSC  Corporate  Logistic'.  Data  Model  (CLDM) 

33.  DoD  CALS  Integrated  Weapon  System  Data  Base  (IWSDB) 

34.  .AECMA  Common  Source  Data  Base  (CSDB) 

35.  CALS/CE ISG  TCAP  EPC  93-4  "Output  Specification  (OS)  Enhancements" 

36.  CALS/CE  ISG  TCAP  EPC  93-5  "Investigate  and  Recommend  how  to  Incorporate  lETM 
Concepts  and  Guidelines  into  MIL-M-2800r' 

37.  CALS/CE  ISG  TCAP  EPC  93-6  "Incorporation  of  Architectural  Forms  into  MIL-M-28()01 
for  "C"  Data  Type  Applications  and  Possible  Inclusion  (or  reference)  to  HyTime" 

38.  CALS/CE  ISG  TCAP  EPC  93-8  "Alignment  of  MIL-M-28001  with  STEP/PDES" 

REPORTS  AND  PAPERS 

5 1 .  "Acquisition  Logistics  Standards  Harmonization  Assessment  Workshop  Report,"  NATO 
AC/301  SG/D  (7  Apr  1993). 

52.  "The  Applicability  of  CALS  to  the  NATO  Countries,"  NATO  Industry  Advisory  Group 
Report  (Oct  1992). 

53.  Military  and  Industry  AECMA  MSWG  SPEC  2000M/LSA  Study  Group  "A  Comparison  of 
AECMA  2000M  (Chapter  1)  and  MIL-STD-1388-2A/2B  Data  Elements,"  (19  Feb  1993). 

54.  UK  Military  Defence  Standard  00-60  "Data  Dictionary." 

55.  "A  Comparison  of  SPEC  2000M  and  MIL-STD-1388-2A/2B  Data  Elements,"  CALS/CE 
ISG  SALSA  Committee  Project  (7  Dec  1992). 
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REFERENCED  DOCUMENTS  (CONTINUED) 

56.  "CALS-LSA  Process  for  lETMs,"  NPPMSO/NAVAIR  Report,  by  Computer  Applications  & 
Systems  Corp.  (Jan  20, 1992). 

57.  Chen,  R.,  "The  Integration  of  the  Air  Force  Content  Data  Model  and  MIL-STD- 1 388-2B," 
Report  DTRC.90/034  (OcT  1990). 

58.  Bean,  J.  "Application  of  Advanced  and  Emerging  Technology  to  ATIS  Processes," 
CALS/CE ISG  Project,  Northrop  B-2  Division  MEMO  L595-93-150  (20  Aug  1993). 

59.  Tilton,  J.  "Why  Wait  for  CALS/CE,"  presented  at  the  48th  Annual  Forum  of  the  American 
Helicopter  Society  (3-5  Jun  1992). 

60.  CALS/LSARIDEFIX  Data  Model 

61 .  CALS/CE  ISG  SALSA  Technical  Committee  working  paper  -  "Covering  an  Opportunity  to 
Further  Integrate  Reliability  and  Maintainability  into  the  MIL-STD- 1388-2B  Data  Base," 

(2  Nov  1993). 

62.  Stormfeltz,  H.  B.,  "An  Industry  Perspective  of  CALS  or  Putting  CALS  in  Its  Place,"  CALS 
Journal,  Winter  (1993). 
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APPENDIX  C  .  STEP  DIS  INITIAL  RELEASE  STANDARDS 


Twelve  STEP  Parts  were  registered  for  Draft  International  Standard  (DIS)  status  in  May 
1993.  This  initial  STEP  release  will  provide  capabilities  for  the  exchange  of  two-dimensional 
drafting  product  data  and  the  conftguration  controlled  exchange  of  three-dimensional  product 
definition  data  with  emphasis  on  mechanical  parts  and  assemblies.  The  initial  STEP  release 
establishes  a  foundation  for  subsequent  STEP  releases.  This  initial  STEP  release  includes  the 
following  Parts: 

Part  1  -  Overview  and  Fundamental  Principles 

Part  1 1  -  EXPRESS  Language  Reference  Manual 

Part  21  -  Clear  Text  Encoding  of  the  Exchange  Structure 

Part  31  -  Conformance  Testing  Methodology 

Part  41  -  Fundamentals  Product  Description  and  Support 

Part  42  -  Geometric  and  Topological  Representation 

Part  43  -  Representation  Structures 

Part  44  •  Product  Structure  Configuration 

Part  46  -  Visual  Presentation 

Part  101  -  Drafting  Part  201  -  Explicit  Drafting 

Part  203  -  Configuration  Controlled  Design 
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APPENDIX  D  -  LIST  OF  OTHER  APS  BEING  DEVELOPED 


Subsequent  STEP  releases  will  provide  added  functionality  and  extend  the  capabilities  of 
the  Initial  Release.  The  schedule  for  these  subsequent  STEP  releases  has  not  been  determined. 
The  following  Parts  are  currently  being  developed. 

Part  22  -  STEP  Data  Access  Interface  (SDAI) 

Part  32  -  Test  Laboratory  Requirements 

Part  33  -  Structure  and  Use  of  Abstract  Test  Suites 

Part  34  -  Abstract  Test  Methods 

Part  4S  -  Materials  Products 

Part  47  -  Shape  Tolerances 

Part  48  -  Form  Features 

Part  104  -  Finite  Element  Analysis 

Part  105  -  Kinematics 

Part  202  -  Associative  Drafting 

Part  204  •  Mechanical  Design  Using  Boundary  Representation 
Part  205  -  Mechanical  Design  Using  Surface  Representation 
Part  206  -  Mechanical  Design  Using  Wireframe  Representation 
Part  207  -  Sheet  Metal  Die  Planning  and  Design 
Part  208  -  Life  Cycle  Product  Change  Process 
Part  209  -  Design  Through  Analysis  of  Composite  &  Metallic  Structures 
Part  210  -  Electronic  Printed  Circuit  Assembly:  Design  and  Manufacture 
Part  21 1  -  Electronic  Printed  Circuit  Assembly:  Test,  Integrated  Diagnostics  and 
Remanufacture 

Part  212  -  Electrotechnical  Plants 

Part  213  -  NC  Process  Plans  for  Machined  Parts 

Part  214  -  Core  Data  for  Automotive  Mechanical  Design 

Part  215  -  Ship  Arrangements 

Part  216  -  Ship  Molded  Forms 

Part  217  -  Ship  Piping  Systems 

Part  218  -  Ship  Structures 

Part  219  -  Dimensional  Inspection  Process  Planning 
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LIST  OF  OTHER  APS  BEING  DEVELOPED  (CONTINUED) 


Part  22U  -  Printed  Circuit  Assembly  Manufacturing  planning 
Part  221  -  Functional  Data  and  Schematic  Representation  for  Process  Plants 
Part  222  -  Exchange  of  Product  Definition  Data  from  Design  engineering  to 
Manufacturing  Engineering  for  Composite  Structures 
Part  223  -  Exchange  of  design  and  Manufacturing  Product  Information  for  Cast 
Part  224  -  Mechanical  products  Definition  for  Process  Planning  using  Form 
Features 

Part  22S  -  Structural  Building  Elements  using  Explicit  Shape  Representation 
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APPENDIX  E  -  THE  STATEMENT  OF  WORK 


ISO  STEP  PRODUCT  LOGISTIC  SUPPORT  APPLICATION  PROTOCOL  SUITE 


1.0  OBJECTIVE 


The  objective  of  the  Product  Logistic  Support  (PLS)  initiative  is  to  develop  STEP 
I'andard  for  the  Exchange  of  Product  data  model)  standards  to  represent  and  exchange 
information  for  product  logistic  support  to  achieve  the  following  goals:  (1)  to  establish  the 
information  requirements  to  ensure  reliable,  maintainable,  and  supportable  products  at  minimum 
life  cycle  cost  by  integrating  data  bases  for  Logistic  Support  Analysis  Record  (LSAR),  Technical 
Manual  (TM),  Provisioning,  and  Order  Administration;  (2)  to  harmonize  existing  European 
AECMA  (Association  European  des  Constracteurs  de  Materiel  Aerospatial)  specifications,  U.S. 
CALS  (Continuous  Acquisition  and  Life-cycle  Support)  standards,  and  other  national  and 
international  standards  in  the  acquisition  logistic  area,  and  (3)  to  meet  both  industrial  and  military 
requirements. 

Currently,  there  is  data  duplication  and  overlap  in  the  LSAR,  TM  (including 
maintenance,  training,  etc.),  and  provisioning  data  bases.  Shared  information  is  not  prepared  once 
and  then  utilized  throughout  each  area  of  a  wetqxin  system  program.  In  many  cases,  the 
organizational  structure  determines  how  the  LSAR,  TM,  and  pan  provisioning  data  are  procured 
and  developed.  As  a  result,  work  is  performed  along  traditional  organizational  lines,  with  little 
consideraticm  of  the  processc'-.  involved.  Therefore,  costs  for  develt^ing  and  updating  the  various 
data  bases  for  LSAR,  TM,  and  parts  provisioning  are  high  due  to  duplications  of  effcnt. 
Additionally,  this  could  result  in  errors  and  inconsistencies  between  the  same  information  in  the 
different  data  bases.  Development  of  the  LSAR,  TM,  and  parts  provisioning  data  should  be 
oriented  to  shared  data  elements  generation  and  should  not  be  oriented  to  product  development. 
Ref.  59  estimates  that  25%  of  development  cost  can  be  eUminated,  if  a  common  shared  data  base 
can  be  develt^red  for  LSAR,  and  TM. 
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The  PLS  AP  Suite  is  designed  as  part  of  the  ISO  STEP  standards  for  the  implementation 
of  a  common  and  shared  integrated  information  environment  for  LSAR,  TM,  parts  provisioning 
and  order  administration. 

2.0  SCOPE 

The  scope  of  this  PLS  AP  suite  is  to  define  the  information  requirements  for  acquisition 
logisi.w^  which  includes  LSAR,  TM,  parts  provisioning,  and  order  administration. 

The  development  of  the  STEP  PLS  AP  suite  shall  be  based  on  existing  technical  data 
standards  and  specifications.  These  jeferenced  standards  and  specifications  (see  Appendix  I)  are: 

MIL-STD-1388-2B:  LSAR  (Logistic  Support  Analysis  Record) 

MIL-M-28001:  SGML  (Standard  Generalized  Markup  Language) 

MIL-D-87269:  lETMDB  (Interactive  Electronic  Technical  Manual) 

AECMA  Spec  2000M:  Material  Provisioning  and  Management 

AECMA  Spec  lOOOD:  Technical  Publication 

ATA  Spec  1(X):  Manufacturers  Technical  Data 

ATA  Spec  2000:  Data  Base  and  Customer  Support 

ISO  10744:  HyTime  (Hypermedia/lime-based  Structuring  Language) 

Other  standards  listed  below  will  also  be  referenced  and  studied: 

MILSTRIP:  Military  Standard  Requisitioning  and  Issue  Procedures 
MILSTRAP:  Military  Standard  Transaction  Reporting  and  Accounting  Procedures 
ATA  Spec  2100:  Digital  Data  Standards  for  Aircraft  Support 
ISO  DIS  10179:  DSSSL  (Document  Style  Semantics  and  Specification  Langu^e) 
IMPAES:  Initial  Multimedia  Presentation  and  Access  Exchange  Specification 

Because  these  standards  were  developed  independently,  most  of  them  are  not  fiilly 
conqiatible  with  each  other.  An  extensive  effort  will  be  needed  to  integrate  and  harmonize  these 
standards  and  specifications. 
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Figure  8  is  the  currently  envisioned  configuration  implementation.  The  actual 
configuration  implementation  can  vary,  if  detailed  analysis  warrants.  It  assumes  that  the  PLS  AP 
suite  (Box  2  of  Fig.  8)  includes  three  STEP  APs  (Boxes  3, 4,  and  S).  A  more  detailed  description 
of  Fig.  8  can  be  found  in  Appendix  F  of  this  report. 


LiWdi:  EFA'EufotMMFIgMw  Alrenlt 

ETH  •EMdronleTwniilMlilanuii 
PLS  •  Praduet  togMIe  Support 


PSA  •  Product  Support  Anolytio 
TOP  -  Toehniool  Dote  PaeWgu 


Fig.  8,  Envfariofwd  pHot  PLS  APs  tanpiemantalion  snvifonmsnt 


The  development  of  PLS  AP  suite  consists  of  two  development  phases  and  one 
demonstration  phase. 


Phase  I  -  Technical  Issues  Assessment  and  PLS  AP  Suite  Development  and 
Demonstration  Planning 


The  fnrst  task  is  to  assess  each  technical  issue  described  in  Appendix  F  of  this  report. 
Next,  establish  the  ftmctional  view  (IDEFO)  of  the  PLS  AP  suite;  develop  key-only  integratable 
and  harmonized  data  models  (IDEFIX)  for  each  of  the  APs  included  in  the  PLS  APs;  develop  a 
data  element  dictionary  from  the  data  models;  assess  the  technical  issues  and  determine  any  risks; 
then  assess  STEP  standards  (both  existing  and  planned),  as  they  relate  to  the  development  of  the 
HJS  APs;  and  determine  relevant  inadequacies.  The  final  task  is  to  prepare  a  plan  to  develop  and 
dememstrate  the  PLS  APs  with  respect  to  a  risk/benefrts  analysis  and  technical  issues  assessment. 
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Phase  n  -  PLS  AP  Suite  Development 


The  Phase  II  tasks  are  to  develop  the  PLS  AP  suite  through  the  development  of 
Application  Reference  Model(s)  (ARMs),  Application  Interpreted  ModeKs)  (AIMs),  and 
conformance  and  test  criteria  (CTC);  identify  enhancements  and  proposed  improvements  for  the 
STEP  Community;  refine  preliminary  activities  to  provide  a  detailed  and  cost  effective 
demonstration  plan;  coordinate  the  development  of  the  AP  suite  with  international  industry  and 
the  standards  organizations  to  facilitate  the  harmonization  of  data  standards;  and  submit  the 
ARMs,  AIMs,  CTC,  and  other  necessary  documents  to  the  ISO  STEP  organization  in  order  to 
qualify  the  PLS  APs  as  ISO  standard(s). 

Phase  in  -  PLS  AP  Suite  Demonstration 

Phase  in  tasks  are  to  demonstrate  the  functionality  of  the  PLS  AP  suite;  project  the 
performance  and  analyze  the  potential  benefits  accming  from  implementing  the  AP  suite  in 
working  environments;  and  debrief  industry  and  government  representatives  on  the  results  and 
potential  impact  of  this  program.  The  contractor  shall  plan  for  the  transfer  of  the  technology 
developed  by  this  program  to  industry. 


3.0  TECHNICAL  REQUIREMENTS 


The  contractor  shall  provide  all  necessary  services,  personnel,  materials,  facilities,  and 
other  items  required  to  accomplish  the  following  tasks  and  satisfy  the  overall  program  objectives. 

3.0.1  Task  1  -  Management  Planning 

The  contractor  shall  develop  and  provide  for  program  management,  addressing:  work 
plans  (wtnk  breakdown  structure  and  responsibility  matrix),  master  schedule  (critical  path 
analysis  and  key  milestones),  subcontract  management,  data  management,  configuration 
management,  and  risk  management.  (CDRL  Data  Item ) 
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3.0.2  Task  2  •  Project  Schedule  and  Control 

The  contractor  shall  monitor  costs,  work  accomplishment  and  adherence  to  schedule  on  a 
monthly  basis.  (CDRL  Data  Item  ) 

3.0.3  Task  3  -  Project  Coordination 

Ongoing  coordination  is  critical  to  PLS  program  success.  The  contractor  shall  establish 
and  maintain  coordination  with  applicable  standards  organizations  and  related  programs  which 
address  similar  areas  of  study.  A  list  of  related  programs  (Refs.  21  to  2S),  projects  (Refs.  31  to 
34)  and  reports  (Refs.  51  to  59)  is  provided  in  Appendix  B.  The  contractor  shall  ensure  that  there 
is  maximum  impact  of  the  program  and  that  no  duplication  of  effort  occurs.  Inter-program 
coordination  shall  include  the  contractor's  technical  understanding  of  the  program(s)'  intent  and 
the  usability  of  the  program(s)'  results.  (CDRL  Data  Item ) 

3.0.4  Task  4  •  Technology  Transfer 

Hie  contractor  shall  plan  for  the  transfer  of  the  technology  developed  in  this  program  to 
industry  and  to  the  governments  of  all  participating  countries.  The  contractor  shall  identify  the 
anticipated  requirements  for  and  the  benefits  of  implementing  this  APs.  This  plan  will  be  updated 
as  requited  throughout  the  program  and  will  be  presented  for  discussion  at  all  program  reviews. 
(CDRL  Data  Item ) 

3.0.5  Task  5  -  Industry  Review  Board 

The  contractor  shall  support  the  Industry  Review  Board  (IRB).  The  IRB  will  provide  a 
ftmim  for  international  industry  (in  particular  the  NATO  lAG,  the  CALS  ISG,  and  the  STEP 
community)  to  review  the  progress  of  this  effort  and  to  offer  guidance.  The  IRB  makeup  shall 
consist  of  members  from  Project  Management  Board  (PMB),  contractors,  the  NATO  lAG  and 
CALS  K»G,  etc.  The  contractor  shall  provide  all  administrative  support,  such  as  preparing  and 
providing  the  meeting  sites,  notifying  the  participants,  moderating  the  meetings,  and  taking  the 
meeting  minutes,  etc.  The  IRB  shall  meet  at  all  review  meetings  specified  by  this  program,  unless 
otherwise  noted  by  the  PMB.  IRB  coimnents  and  recommendations  resulting  from  review 
meetings  shall  be  considered  and  acted  upon  when  the  PMB  deems  them  iqipropriate.  The  initial 
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composition  of  the  IRB  and  changes  to  its  composition  during  the  course  of  the  contract  are 
subject  to  the  approval  of  the  PMB.  (CDRL  Data  Item  ) 

3.0.6  Task  6  -  PLS  AP  Suite  Kick-Off  Meeting 

The  contractor  shall  conduct  an  initial  meeting  to  discuss  draft  versions  of  the  Project 
Master  Plan  and  the  Project  Planning  Chart.  The  contractor  shall  present  for  review  the  format  for 
the  Contract  Fund  Status  Report,  the  Funds  and  Man-Hour  Expenditure  Report,  the  Contractor's 
Voucher,  and  the  Scientific  and  Technical  Reports.  The  contractor  shall  also  be  prepared  to 
discuss  the  technical  details  of  the  contractor's  proposal  and  the  contractor  team's  work 
assignments,  and  coordinate  efforts  to  accomplish  the  requirements  of  the  statement  of  work.  The 
initial  meeting  shall  be  held  within  40  days  after  contract  award.  (CDRL  Data  Item  ) 

The  contractor  shall  not  proceed  with  Phase  I  without  written  notice  to  proceed  from  the 
PMB.  (CDRL  Data  Item ) 

3.1  Phase  I  -  Technical  Issues  Assessment  and  PLS  AP  Suite  Development  Strategy 

This  phase  shall  assess  and  resolve  all  identified  technical  issues  related  to  the  PLS  AP 
suite  development,  and  also  provide  a  plan  for  the  development  and  demonstration  of  the  AP  suite 
to  be  used  in  Phases  IL  and  m  respectively. 

3.1.1  Task  1 1  -  Technical  Issues  Assessment 

The  technical  issues  crucial  to  the  PLS  AP  suite  development  effort  shall  first  be 
thoroughly  analyzed  and  studied  by  the  contractor.  All  proposed  technical  solutions  shall  be 
presented  to  and  agreed  upon  by  the  IRB  and  then  approved  by  the  PMB  before  proceeding  to 
Phase  n  of  this  contract.  (CDRL  Data  Item  ) 

3.1. 1.1  Task  1 1.1  -  Analyze  the  Scope  and  Configuration  of  the  PLS  AP  Suite 

Hie  contractor  shall  develop  and  propose  the  PLS  AP  suite  configuration  implementation 
with  respect  to  both  Fig.  8  and  Section  2  of  Appendix  F.  The  contractor  shall  propose  the  scope  of 
the  PLS  APs  and  analyze  the  data  flow  among  the  APs.  The  contractor  shall  also  analyze  the  ALA 
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Spec  2100  program  with  regard  to  the  impact  on  the  PLS  AP  suite  development  effort.  The  results 
of  this  analysis  shall  be  presented  to  the  IRB  for  comments  and  to  PMB  for  acceptance.  (CDRL 
Data  Item ) 

3. 1.1.2  Task  1 1.2  -  Analyze  the  MIL-STD-1388  Enhancements 

The  contractor  shall  analyze  the  eni;.^cements  of  MIL-STD-1388  and  propose  solutions. 
The  enhancements  to  be  investigated  shall  include  but  shall  not  be  limited  to  their  descriptions  in 
Section  3  of  Appendix  F.  The  contractor  shall  opose  technical  solutions  to  the  IRB  for 
comments.  The  contractor  shall  implement  an>  of  the  proposed  solutions  accepted  by  the  IRB  and 
approved  by  PMB.  The  contractor  shall  work  closely  with  Joint  Service  LSA  Technical  Working 
Group.  (CDRL  Data  Item ) 

3. 1.1. 3  Task  1 1.3  -  Analyze  the  Integr^on  Key  Implementation 

The  contractor  shall  analyze  the  technical  issues  regarding  the  integration  key  and 
propose  a  solution.  The  investigation  shall  include  but  shall  not  be  limited  to  the  proposal  in 
Section  4  in  Appendix  F.  The  contractor  shall  propose  a  technical  solution  to  the  IRB  and  shall 
implement  any  proposed  solution  accepted  by  the  IRB  and  £q)proved  by  the  PMB.  (CDRL  Data 
Item ) 

3. 1 . 1 .4  Task  1 1.4  -  Perform  Functional  Activity  Analysis 

The  contractor  shall  develop  a  two-Ievel  functional  analysis  of  the  PLS  APs  using  IDEFD 
methodology.  The  contractor  shall  first  collect  and  analyze  all  previous  relevant  material  (Refs. 
22, 31  to  34).  The  contractor  shall  present  the  IDEFO  to  the  IRB  for  comments  and  approval  by 
the  PMB.  (CDRL  Data  Item ) 

3.1. 1.5  Task  1 1.5  -  Analyze  the  Integration  of  PSA  and  ETM  APs 

The  contractor  shall  analyze  the  technical  issues  regarding  the  integration  of  PSA  and 
ETM  APs  and  propose  solutions.  The  investigation  shall  include  but  shall  not  be  limited  to  the 
descriptions  in  Section  5  of  Appendix  F.  The  contractor  shall  propose  technical  solutions  to  the 


49 


IRB  and  shall  implement  any  proposed  solution  accepted  by  the  IRB  and  approved  by  the  PMB. 
(CDRL  Data  Item ) 


3.1 .1 .6  Task  1 1 .6  -  Analyze  the  Integration  of  AECMA  lOOOD  and  MIL-D-87269 

The  contractor  shall  analyze  the  technical  issues  regarding  the  integration  of  AECMA 
lOOOD  and  MIL-D-87269  and  propose  solutions.  The  investigation  shall  include  but  shall  not  be 
limited  to  the  descriptions  in  Section  6  of  Appendix  F.  The  contractor  shall  work  closely  with  the 
SGML  standards  development  organizations,  i.e.,  the  Tri-Service  Working  Group  for  DETM,  the 
CALS  ISG  Electronic  Publication  Committee,  and  the  ISO  STEP  Technical  Publication 
Committee.  The  contractor  shall  propose  technical  solutions  to  the  IRB  and  shall  implement  any 
proposed  solutions  accepted  by  the  IRB  and  approved  by  the  PMB.  (CDRL  Data  Item  ) 

3. 1.1.7  Task  1 1.7  -  Analyze  the  DTDs  for  the  Training  TM 

The  contractor  shall  analyze  the  technical  issues  regarding  the  development  of  DTDs  for 
the  training  TM  and  propose  solutions.  The  investigation  shall  include  but  shall  not  be  limited  to 
the  descriptions  in  Section  7  of  Appendix  F.  The  contractor  shall  propose  technical  solutions  to 
the  IRB  and  shall  implement  any  proposed  solutions  accepted  by  the  IRB  and  approved  by  the 
PMB.  (CDRL  Data  Item ) 

3.1. 1.8  Task  1 1.8  -  Analyze  the  Integration  of  AECMA  20(X)M  and  MIL-STD-1388-2B 

The  contractor  shall  analyze  the  technical  issues  regarding  the  integration  of  AECMA 
2(XX)M  and  MIL-STD-1388-2B  and  propose  solutions.  The  investigation  shall  include  but  shall 
not  be  limited  to  the  descriptions  in  Section  8  of  Appendix  F.  The  contractor  shall  propose 
technical  solutions  to  the  IRB  and  shall  implement  any  proposed  solution  accepted  by  the  IRB 
and  approved  by  PMB.  (CDRL  Data  Item ) 

3.1 .1 .9  Task  1 1 .9  -  Analyze  the  Integration  of  AECMA  2(XX)M  and  MIL-STRIP/STRAP 

The  contractor  shall  analyze  the  technical  issues  regarding  the  integration  of  AECMA 
2(XX)M  and  MIL-STRIP/STRAP  and  propose  solutions.  The  investigation  shall  include  but  shall 
not  be  limited  to  the  descriptions  in  Section  9  of  Appendix  F.  The  contractor  shall  propose 
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technical  solutions  to  the  IRB  and  shall  implement  any  proposed  solution  accepted  by  the  IRB 
and  approved  by  the  PMB.  (CDRL  Data  Item ) 

3.1.1.10  Task  11.10 -Develop  Data  Models 

The  contractor  shall  develop  data  models  for  each  of  the  proposed  PLS  APs  using 
IDEFIX  methodology.  Each  AP  data  model  (key-only)  shall  be  the  result  of  the  harmonization 
and  integration  of  the  respective  data  models  of  the  standards  and  specifications.(Section  10  of 
Appendix  I)  All  the  AP  data  models  developed  shall  share  a  common  set  of  data  elements.  The 
contractor  shall  present  the  data  models  to  the  IRB  which  shall  be  accepted  by  the  IRB  and 
approved  by  PMB.  (CDRL  Data  Item ) 

3. 1.1.1 1  Task  1 1.1 1  -  Develop  Data  Dictionary 

The  contractor  shall  compile  a  draft  of  a  common  data  dictionary  as  a  result  of  Task 
11.11.  The  data  dictionary  shall  use  the  format  specified  by  DoD  8320.  The  data  dictionary  shall 
be  presented  to  the  IRB  and  approved  by  PMB.  (CDRL  Data  Item ) 

3.1.1.12  Task  11.12  -  Conduct  Technical  Issues  Review  Meetings 

The  contractor  shall  schedule  and  coordinate  IRB  meetings,  at  PMB  approved  sites,  to 
review  the  results  of  preceding  analyses.  The  contractor  shall  present  the  study  results,  proposed 
solutions,  and  implementations  of  the  proposed  solutions.  The  contractor's  presentation  shall 
include  the  minimum;  any  technical  risk,  schedule  risk,  implementation  impact,  benefit  to  NATO 
and  industry,  and  performance  factors.  The  contractor  shall  identify  the  factors  that  must  be 
addressed  and  satisfactorily  resolved  during  this  program  for  the  AP  suite  to  be  considered  a 
success.  The  contractor  shall  respond  to  conunents  and  action  items  that  arise.  (CDRL  Data  Item ) 

3.1.2.1  Task  12.1  -  Assess  STEP  Inadequacies 

The  contractor  shall  assess  and  evaluate  current  STEP  content  and  scope  to  determine  the 
STEP  capability  for  supporting  the  development  of  this  AP  suite.  This  process  shall  be  a  detailed 
continuation  of  the  preliminaiy  STEP  assessment  provided  in  the  proposal.  The  contractor  shall 
forecast  the  progress  of  STEP  planned  activities  and  emerging  technologies  that  can  contribute  to 
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and  impact  on  this  program.  The  contractor  shall  also  identify  the  STEP  inadequacies  where  the 
PLS  APs  needs  are  not  supported  by  STEP.  The  contractor  shall  estimate  the  time  and  the  cost  of 
eliminating  deficiencies  from  the  ISO  STEP  standards.  (CDRL  Data  Item ) 


3.1.3  Task  13  -  Produce  an  AP  Suite  Development  and  Demonstration  Strategy 

3. 1 .3. 1  Task  13.1-  Develop  Criteria 

The  contractor  shall  develop  a  set  of  criteria  against  which  the  potential  costs  and  benefits 
of  filling  each  inadequacy  identified  in  Tasks  1 1  and  12  can  be  measured  in  relation  to  NATO 
requirements  to  utilize  the  PLS  APs.  The  contractor  shall  document  the  set  of  criteria  which  will 
include  at  the  minimum:  technical  risk,  schedule  risk,  implementation  impact,  benefit  to  NATO 
and  industry,  performance,  and  cost  of  each  inadequacy  elimination.  The  contractor  shall  also 
identify  the  tasks  that  must  be  completed  and  satisfactorily  demonstrated  during  this  program  for 
the  AP  suite  to  be  considered  a  success.  (CDRL  Data  Item ) 

3.1.3.2  Task  13.2  -  Develop  the  AP  Suite  Scope 

Using  the  technical  issues  analyzed  in  Tasks  1 1  and  12,  and  the  criteria  set  identified  in 
Task  13.1  the  contractor  shall  analyze  and  define  the  cost/benefits  of  eliminating  each  of  the 
identified  inadequacies.  The  contractor  shall  place  the  inadequacies  in  priority  sequence  and  shall 
propose  which  inadequacies  should  be  addressed  during  Phase  n  of  this  contract.  The  contractor 
shall  also  identify  precisely  the  scope  of  this  AP  suite  using  IDEFO  methodology.  (CDRL  Data 
Item) 


3.1.3.3  Task  13.3  -  Plan  AP  Suite  Development 

Based  upon  the  results  of  the  scoping  activities  (Task  13.2),  the  contractor  shall  provide  a 
plan  for  the  definition  of  functional  needs  through  the  development  of  an  AP  suite.  This  approach 
shall  be  documented  in  terms  of  a  plaiming  model.  The  contractor  shall  highlight  the 
incorporation  of  other  STEP  related  models  under  development  by  other  organizations  and  the 
methodology  for  harmonizing  these  efforts,  if  applicable.  (CDRL  Data  Item ) 
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3. 1.3.4  Task  13.4  -  Plan  AP  Suite  Data  Transferring  Demonstration 

The  contractor  shall  propose  a  plan  for  the  Phase  111  demonstration.  The  data  necessary 
for  population  of  the  data  base  instantiated  with  the  APs  shall  be  provided  by  the  contractor,  after 
approval  by  the  PMB  through  the  contracting  officer.  The  demonstration  planning  shall  be 
designed  but  will  maintain  sufficient  flexibility.  At  the  minimum,  the  demonstration  shall  include 
exchange  in  a  heterogeneous  environment  such  as  a  prime  contractor  to  subcontractor  exchange 
and  a  prime  contractor  to  NATO  exchange.  Potential  AP  suite  implementation 
issues/impediments  shall  be  documented  with  an  assessment.  (CDRL  Data  Item ) 

3.1.4  Task  14  -  Critical  Review  of  End  of  Phase  I 

The  contractor  shall  conduct  an  end  of  Phase  I  review  at  a  PMB  approved  site.  The 
results  of  all  technical  analyses  of  Phase  I  shall  be  presented.  Particular  attention  shall  be  focused 
on  the  following:  analysis  of  technical  issues,  identification  of  all  risks,  risk  mitigation  plans,  AP 
suite  development  planning,  and  demonstration  planning.  The  contractor  shall  resolve  comments 
and  action  items  that  arise.  The  contractor  shall  update  the  estimated  time  and  costs  for  each  task 
in  Phases  II  and  HI.  The  results  of  this  review  will  form  the  basis  for  the  PMB  to  determine 
whether  or  not  to  recommend  that  the  contractor  proceed  with  Phase  n.  The  contractor  shall  not 
proceed  with  Phase  II  without  written  notice  from  the  PMB.  (CDRL  Data  Item ) 

3.2  Phase  II  -  PLS  AP  Suite  Development 

This  phase  shall  provide  for  the  development  and  specification  of  required  models,  as 
well  as  the  mappings  and  test  criteria  needed  to  support  the  functionality  resulting  from  Phase  I. 

3.2.1  Task  21  •  Develop  Application  Reference  Model  (ARM) 

The  contractor  shall  develop  a  human  interpretable  user  view  of  the  application 
dependent  information  needs  and  specify  them  in  the  form  of  an  ARM.  (CDRL  Data  Item ) 


53 


3.2.1. 1  Task  21.1  -  Develop  AP  Suite  Scope  and  Content 

Based  on  the  results  of  Phase  I,  the  contractor  shall  refine  the  scope  and  content  of  the  AP 
suite.  This  shall  include  an  IDEFO  activity  model  of  the  selected  activities  to  be  supported. 

(CDRL  Data  Item ) 

3.2. 1.2  Task 21.2 -Develop ARMS 

The  contractor  shall  develop  a  set  of  human  interpretable  ARMs  from  an  end  user's 
viewpoint,  which  delineate  the  information  needs  of  the  AP  suite  scope  from  3.2.1 .1 .  The  ARMs 
shall  be  documented  using  the  IDEFIX  structured  modeling  technique.  (The  contractor  may  make 
a  written  request  to  the  PMB  to  consider  using  other  graphical  modeling  techniques,  such  as 
NIAM  or  EXPRESS-G,  in  place  of  IDEFIX.)  User  context  driven  test  and  validation  criteria  for 
the  ARMs  shall  be  specified.  (CDRL  Data  Item ) 

3.2.1. 3  Task  21.3  -  Review  ARMs 

The  contractor  shall  conduct  a  meeting,  at  a  PMB  approved  site,  to  review  the  results  of 
work  performed  under  Sections  3.2. 1.1  and  3.2. 1.2.  The  contractor  shall  resolve  comments  and 
action  items  that  arise.  (CDRL  Data  Item  ) 

3.2.2  Task  22  -  Develop  AIM 

For  each  ARM  identified  in  Section  3.2. 1.3  the  contractor  shall  develop  a  complete, 
detailed  computer  intetpretable  AIM. 

3.2.2. 1  Task  22.1  -  Information  Model  Development 

The  contractor  shall  develop  a  complete  information  nuxlel  of  the  information  needs 
identified  by  the  ARM.  Suitable  STEP  constructs  already  defined  in  the  Integrated  Resources 
Model  (IRM)  shall  be  used  whenever  possible.  Additional  constructs  needed  to  fill  the  identified 
inadequacies  shall  be  developed.  (CDRL  Data  Item ) 
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3.2.2.2  Task  22.2  -  Review  ISO/STEP 

As  an  aid  to  technology  transfer,  the  contractor  shall  conduct  a  meeting  with  the 
ISO/STEP  organization  to  review  potential  IRM  shortcomings  (both  entity  and  methodological) 
and  any  additional  information  constructs  developed  in  Section  3.2.2. 1.  (CDRL  Data  Item ) 

3. 2.2.3  Task  22.3  -  Document  AIM 

The  contractor  shall  document  the  AIM  developed  in  Section  3.2.2. 1  by  means  of  the 
EXPRESS  language.  Two  models  shall  be  specified.  The  first  is  a  Short  Form  model  consisting  of 
an  EXPRESS  mapping  from  the  IRM  and  the  additional  constructs  needed  to  support  the  APs. 

The  second  is  an  Expanded  Model  resulting  from  applying  the  mapping.  The  Expanded  Model 
shall  be  completely  interpretable  and  understandable  without  reference  to  the  IRM 
documentation.  (CDRL  Data  Item ) 

3.2.3  Task  23  •  Develop  Test  and  Conformance  Criteria 

The  contractor  shall  develop  and  document  conformance  criteria,  tests,  and  demonstration 
scenarios  for  each  AIM  and  ARM.  Demonstration  scenarios  for  the  purpose  of  evaluating  the  AP 
suite  against  the  conformance  criteria  and  the  validation  criteria  identified  in  Section  3.2. 1.2  shall 
be  developed.  The  test  criteria  shall  be  developed  fuat  for  the  LSAR,  AECMA  SPEC  2000M 
(Chapter  1),  and  lETMDB  views.  (CDRL  Data  Item  ) 

3.2.4  Task  24  -  Review  Application  Ihutocol  Suite 

The  contractor  shall  conduct  a  meeting,  at  a  PMB  approved  site,  to  review  the  results  of 
Phase  n.  The  contractor  shall  resolve  comments  and  action  items  that  arise.  Any  resulting 
changes  in  the  AP  suite  specifications  shall  be  documented  for  PMB  approval.  The  results  of  the 
review,  coupled  with  detailed  analyses  of  how  the  ARM,  the  AIM,  and  the  Test  Criteria 
synergistically  combine  to  form  the  AP  suite  specifications  will  form  the  basis  of  the  PMB 
recommendation  on  whether  or  not  to  proceed  with  Phase  m.  Cost,  benefit,  and  risk  analyses 
supporting  demonstration  decisions  shall  be  performed  as  a  function  of  the  demonstration 
sceruuios  (Section  3. 1.3 .4).  The  contractor  shall  not  proceed  with  Phase  m  without  written  notice 
to  proceed  from  the  PMB.  (CDRL  Data  Item ) 
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3.3  Phase  III  -  PLS  AP  Suite  Demonstration 


This  phase  shall  demonstrate  and  validate  the  application  protocol  suite  developed  in 
Phase  II. 

3.3.1  Task  31  -  Refute  Demonstration  Planning 

Based  upon  the  information  provided  during  the  Application  Protocol  Suite  review 
(Section  3.2.4),  the  contractor  shall  refine  the  demonstration  plan  (Section  3. 1.3.4)  as  required  to 
ensure  that  the  latest  version  of  the  AP  suite  is  demonstrated  and  validated  in  a  cost  effective 
manner.  (CDRL  Data  Item ) 

3.3.2  Task  32  -  Demonstrate  the  PLS  AP  Suite 

The  contractor  shall  demonstrate  the  APs  developed  in  Phases  I  and  n.  The 
demonstration  shall  be  executed  according  to  the  plan  developed  in  Section  3.1 .3.4  and  refmed  in 
Section  3.3.1.  Demonstration  results  and  any  necessary  changes  to  the  AP  suite  specifications 
shall  be  documented.  (CDRL  Data  Item ) 

3.3.3  Task  33  •  Final  Analysis  of  Program  Perfcmnance  and  Beneflts  Analysis 

The  contractor  shall  collect  data  about  the  PLS  AP  suite  performance  from  the  results  of 
the  demonstration.  The  contractor  shall  address  the  potential  for  AP  suite  related  implementations 
for  logistic  support  and  shall  analyze  business  case  requirements  for  the  implementation  of  this 
and  other  AP  suite  programs.  (CDRL  Data  Item  ) 

3.3.6  Task  36  -  Crqiture  the  Product  Data  for  the  Demonstration 

The  product  data  for  the  demonstration  shall  be  crqrtured.  (CDRL  Data  Item ) 
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4.0  DELIVERABLE 


4.1  Data  requirements  shall  be  strictly  in  accordance  with  DD  Form  1423,  Contract  Data 
Requirements  List. 


5.0  SPECIAL  CONSIDERATIONS 

5.1  Industry/Govemment  Debriefing.  The  contractor  shall  conduct  a  debriefing 
subsequent  to  completion  of  the  technical  effort.  The  purpose  of  the  debriefing  shall  be  the 
transmission  of  the  salient  results  of  this  program  in  a  timely  marmer  to  appropriate 
representatives  from  industry  and  government.  Feedback  from  this  debriefing  shall  be  solicited 
and  documented  as  appropriate.  The  contractor  shall  develop  a  professional  quality  display  board 
and  a  professional  quality  video  ta^ie  which  illustrate  the  program's  history,  phases,  findings, 
conclusions,  and  benefits.  (CDRL  Data  Item ) 

5.2  Environmental  Impact.  The  contractor  shall  assess  the  environmental  consequences 
of  the  concepts  being  developed  from  the  standpoint  of  the  program.  (CDRL  Data  Item ) 


This  draft  SOW  was  reviewed  and  enhanced  at  the  CALS/CE ISG  SALSA  third  quarterly 
technical  working  group  meeting  on  2  September  1993  with  the  following  attendees: 


EUis  Atkinson 
Pnter  Bergmann 
Ruey  Chen 
Sandra  Facon 
Dane  Gayle 
Michael  Hum 
Lisa  Kove 


LOGSA 

Deutsche  Aerospace/AECMA,  Germany 
Naval  Surface  Warfare  Center 
Northrop  Corporation 
Airoliv,  Inc.,  U.S. 

Texas  InstrumentsCorporation 
Joint  Logistic  System  Center 
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CALS/CE ISG  SALSA  COMMITTEE  (CONTINUED) 


Tom  Kulik 
John  McLaughlin 
Tom  Parker 
Gary  Smith 
Nick  Smith 
Garry  Waters 

Additional  participants  at  the  SALSA  fourth  quarterly  working  group  meeting,  held  on  2 
November  1993  (CALS  Expo  ‘93),  include: 


John  Bean 

Northrop  Corporation 

Hobest  L.  Bienvenu 

Ministry  of  Defence,  France 

Bobby  Chin 

Battelle 

Bernard  Dumez 

GAT  Industries,  France 

James  A.  Hayes 

Lockheed  ASG 

Jarl  S  Maguusson 

Defence  Department,  Sweden 

AlanPfcltzman 

OSD/DISACFS 

Rene  J.  Pistenon 

Ministry  of  Defence,  France 

Michel  Rodriavez 

AEROSPATIALE,  France 

Yuri  Rubinsky 

Soft  Quad  Inc.,  Canada 

Mick  Smith 

Ministry  of  Defence,  Army,  UK 

Davis  R.  Watts 

Ministry  of  Defence,  Army,  UK 

McDonnell  DtMiglas  Corporation 
Lockheed  Company  (Forth  Worth) 
Defense  Logistics  Agency 
Joint  Logistic  System  Center,  U.S. 
Alliant  TechSystems,  U.S. 

AF  Space  System  Division 


S8 


APPENDIX  F  .  TECHNICAL  ISSUES 


In  the  development  of  the  STEP  PLS  AP  suite,  there  are  many  technical  issues  that  need 
to  be  understood,  analyzed,  agreed  upon,  and  resolved.  The  technical  issues  crucial  to  the  PLS  AP 
suite  development  include  the  following; 

1 .0  DATA  MODELING  AND  DATA  MODEL  INTEGRATION 

The  most  critical  aspects  of  any  modem  information  system’s  methodology  are: 
specifying  the  user's  information  requirements,  validating  these  requirement  specifications,  and 
converting  them  into  data  base  designs.  Conceptual  data  modeling  has  been  used  to  fulfill  these 
needs.  Conceptual  data  modeling  is  becoming  one  of  the  most  powerful  techniques  for 
establishing  and  maintaining  control  over  information  resources.  Data  models  are  used  to 
represent  conceptual  schemes  and  to  help  integrate  the  information  resources. 

Figure  9  shows  how  the  logical  (conceptual  scheme)  view  of  data  can  be  mapped  to  the 
various  physical  DBMS  data  base  structures  (internal  schemes)  as  they  are  identified, 
implemented,  and  mapped  to  the  user  views  (external  schemes).  Integrating  large  data  resources 
without  using  data  models  can  be  very  difficult. 


LigiBdi;  caOB-OomnMnaeiHcaCMiaaM  ETH-EtielranleTMMMeallliniMl 

OTD-MlTypalMlnUDii  IMDB  •  HlMgMad  WMpon  SyMm  DMa  BaM 

IVA-biiapawFIgM*  Akcratt  kSA'AradueiattppM  Anaiyala 

Fig.  9.  IntagraUen  of  P8A,  ETM  and  oVmt  data  moMs. 
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The  CALS  approach  to  integrating  technical  data  information  systems  requires  an 
integrated  conceptual  data  model  to  control  and  coordinate  all  of  the  technical  information 
systems  supporting  a  weapon  system.  This  concept  of  an  integrated  data  model  (which  will 
include  a  logical  collection  of  shared  data  models  to  support  all  technical  information  system 
users)  is  called  the  CALS  IPDB  (Integrated  Product  Data  Base)  /  IWSDB  (Integrated  Weapon 
System  Data  Base)  or  Common  Source  Data  Base  (CSDB)  which  will  provide  the  basis  for  the 
integrated  shared  data  environment.  The  development  of  the  ISO  STEP/PDES  standards  will 
enable  information  systems  to  use  a  standardized  digital  representation  (data  models)  for  product 
data.  It  will  provide  a  complete,  unambiguous,  digital  definition  of  the  physical  and  functional 
characteristics  of  each  element/part  of  a  product  throughout  its  life  cycle. 

The  challenge  in  developing  this  PLS  AP  suite  is  the  development  of  integratable  data 
models  based  on  the  existing  data  standards  and  specifications  which,  in  most  cases,  are  not 
compatible  with  each  other. 


2.0  PLS  AP  SUITE  IMPLEMENTATION  ENVIRONMENT 


The  following  paragraph  describes  the  contents  of  Fig.  8: 

Box  1  -  Technical  Data  Package  (TDP)  APs:  This  box  represents  the  STEP  TDP  APs 
which  will  provide  product  deftnition  input  such  as  engineering  drawing,  graphics,  bills  of 
material,  etc.  The  proposed  TDP  AP  suite  being  cteveloped  is  based  on  MIL-T-31000  to  meet 
DoD  and  industry  requirements  on  the  transferring  of  technical  data  packages.  Chapter  1C  of 
AECMA  20(X)M  (for  preparing  the  IPC)  should  be  harmonized  with  MIL-T-31000. 

Box  2  -  PLS  AP  Suite;  The  PLS  AP  suite  will  include  at  least  three  APs  (Boxes  3, 4, 

andS). 


Box  3  -  Electronic  Technical  Manual  (ETM)  AP:  This  is  the  harmonization  of  MIL-D- 
87269  and  AECMA  1(X)0D.  See  Section  6  of  this  ^pendix  for  a  detailed  description. 
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Box  4  -  Product  Support  Analysis  (PSA)  AP;  TTiis  is  the  harmonization  of  MIL-STD- 
1388-2B  and  Chapters  1 A  and  IB  of  AECMA  SPEC  2(X)0M.  See  Section  8  of  this  appendix  for  a 
detailed  description  of  this  AP. 

The  PSA  AP  is  a  proposed  STEP  AP  which  was  submitted  to  ISO  STEP  in  September 
1993  for  approval.  This  is  the  result  of  a  year-long  effort  on  the  part  of  the  Product  Life  Cycle 
Support  technical  committee  of  the  IGES/PDES  Organization  to  produce  this  proposed  PSA  AP. 
The  development  of  this  PSA  AP  is  also  the  first  attempt  to  introduce  existing  DoD  military  data 
standards  into  the  ISO  STEP/PDES  community. 

Box  5  -  Order  Administration  AP:  This  is  the  harmonization  of  MILSTRIP/STRAP  and 
the  Procurement  Planning,  Order  Administration,  and  Invoicing  sections  of  AECMA  2000M 
(Chapters  2  to  S).  See  Section  9  of  this  appendix  for  a  detailed  description  of  this  AP. 

Boxes  6, 7  and  8  -  These  three  boxes  represent  various  forms  of  TM  output  from  the 
ETM  AP  instance. 

Box  9  •  This  box  represents  the  in-service  use  of  the  maintenance  and  training  TMs. 

Box  10  -  Manufacturing  or  remanufacturing 

3.0  ENHANCEMENT  OF  MIL-STD-1388 

The  NATO  Harmonization  Assessment  Workshop  in  Acquisition  Logistics  Standards 
(Ref.  51)  recommended  that  the  scope  of  MIL-STD-1388  be  expanded  to  include  the  following 
functions.  The  introduction  of  these  processes  may  require  additional  data  elements. 

a.  Logistic  Support  Analysis  for  Software 

The  majority  of  product  or  weapon  systems  used  in  an  integrated  weapons  platform 
require  the  use  of  software.  However,  there  appears  to  be  no  process  described  in  MIL-STD- 
1388-lA  that  requires  an  LSA  type  of  process  to  be  applied  to  software  design  to  enable  the 


inclusion  of  supportability  features.  The  principles  of  the  LSA  process  can  be  applied  to  software 
and  it  is  therefore  considered  feasible  that  support  analysis  for  software  can  be  achieved. 


b.  Equipment  Disposal  and  Recycle  Analysis 

The  disposal,  decommisioning  (demilitarizing),  and  recycling  aspects  of  equipment 
constitute  an  important  life  cycle  phase  with  regard  to  the  determination  of  support  analysis.  The 
present  MIL-STD- 1388-1 A  tasks  do  not  directly  address  the  identification  of  disposal  tasks  and 
leave  much  of  the  interpretation  to  the  reader.  In  any  event,  recycle  analysis  is  not  considered. 
The  various  aspects  of  disposal,  decommisioning,  and  recycle  analysis  would  be  better  defined  in 
terms  of  specific  sub-tasks  describing  the  requirements  for  identifying  the  associated  logistic 
support  requirements. 

c.  Surge  Production 

Certain  equipment  items  can  become  critical  because  of  increased  need  in  times  of  crisis. 
The  existing  Tasks  in  the  303  and  401  series  of  Mn..-STD-1388-lA  can  be  interpreted  as 
identifying  those  logistic  support  requirements  resulting  from  a  change  in  rate  of  utilization.  This 
gives  rise  to  the  requirement  for  surge  production  of  critical  items  in  response  to  operational 
needs. 


d.  Candidate  Item  Selection  Procedure 

LSA  is  carried  out  on  items  that  are  considered  to  be  maintenance  significant.  Customer 
and  contractor  generated  lists  of  candidate  items  which  have  already  been  written  in  both  the  LSA 
Strategy  and  LSA  Plans.  The  procedure  of  selection  criteria  for  identifying  candidate  items 
should  be  described  in  greater  detail. 

e.  Reliability  and  Maintainability 

To  ensure  that  the  delivered  we^ion  system  is  both  reliable  and  logistically  supportable 
in  the  field,  a  common  means  of  tracking  failures  during  and  after  the  system  is  built  is  a  primary 
requirement.  Failure  Reporting  and  Corrective  Action  System  (FRACAS)  requirements  were 
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originally  defined  in  MIL-STD-2155.  In  today's  digital  environment,  this  standard  is  nearly 
obsolete. 


Most  Failure  Modes,  Effects  and  Criticality  Analysis  (FMECA)  information  is  based  on 
theory.  By  including  Failure  Reporting  and  Corrective  Action  System  (FRACAS)  data  in  the 
LSAR  data  base,  theoretical  part  failures  can  be  compared  against  actual  part  failures. 
Additionally,  malfunctions  can  be  identified  for  verification  of  initial  LSAR  data. 

Reference  61  recommends  that  FRACA  reporting  become  a  part  of  the  MIL-STD-1 388- 
2B  data  base  capabilities.  MIL-STD-215S  should  be  enhanced  to  directly  support  data  collection 
within  the  LSAR  data  bases. 


4.0  INTEGRATION  KEY 


The  activities  of  engineering  design,  LSA,  technical  documentation,  and  initial 
provisioning  need  a  mechanism  to  provide  an  integrated  cross  reference  capability.  A  single 
integration  key  is  needed  to  cross  reference  each  technical  subject  area. 

The  NATO  Standard  Harmonization  Workshop  (Ref.  SI)  recommends  the  development 
of  a  relational  data  table  (data  model)  to  define  an  integration  key.  The  base  control  value  for  each 
record  of  the  relational  table  is  its  LCN/ALC  combination.  This  relational  table  can  be  used  to 
cross  reference  the  design  engineering  control  number,  the  logistics  LSA  control  number,  the  IP 
project  number,  and  the  technical  documentation  control  number.  For  example,  the  LSA  control 
number  can  be  built  on  the  structure  of  the  LSA/ALC  and  LSAR's  Task  Code. 

This  approach  does  not  require  the  development  of  any  new  data  elements,  but  rather  uses 
a  management  activity  to  align  and  normalize  the  data  between  functional  activities.  Other 
technical  disciplines  can  be  added  to  the  table  without  changing  the  existing  structure  or  any 
existing  relationships. 
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5.0  INTEGRATION  OF  THE  PSA  AND  ETM  APS 


Figure  9  shows  the  envisioned  integration  of  the  PSA,  ETM,  and  other  related  data 
models  in  the  ISO  STEP  environment. 

The  benefits  of  integrating  the  LSAR  with  ETM  data  bases  are  well  known  (Refs.  56  to 
59).  Some  companies  have  experienced  a  cost  reduction  of  more  than  25  percent  in  ETM 
authoring  by  integrating  the  LSAR  and  ETM  data  bases  to  improve  the  LSAR  and  ETM 
authoring  processes. 

A  common  practice  of  ETM  development  is  to  first  develop  the  related  LSAR  data  base 
and  then  use  it  as  source  data  in  authoring  a  ETM.  A  preferred  procedure  for  ETM  development 
is  to  combine  the  two  processes  into  one  process  which  requires  the  integration  or  alignment  of 
the  LSAR  and  lETMDB  data  bases.  This  one  step  process  can  considerably  diminish  ETM 
develc^ment  time  and  cost  and  also  greatly  enhance  quality  and  productivity. 

The  main  concern  of  this  PLS  program  is  the  two  levels  of  integration  shown  in  Fig.  9. 
The  oblong  rectangular  shape  in  Fig.  9  represents  the  first  level  of  integration.  It  addresses  the 
integration  of  various  SGML  ETM  DTDs  (data  models).  The  second  level  addresses  the 
integrated  ETM  DTDs  with  PSA  (based  on  MIL-STD-1388-2B  and  AECMA  2(X)0M)  and  other 
related  data  models. 

For  example,  with  regard  to  the  first  level  of  integration  the  0-level  maintenance  DTD 
(based  on  MIL-D-87269)  and  the  EFA  DTD  of  AECMA  lOOOD  are  not  compatible  with  each 
other.  Detailed  discussions  of  the  harmonization  of  these  two  DTDs  can  be  found  in  Section  6. 

With  regard  to  the  second  level  of  integration,  the  PSA  and  the  ETM  DTD  data  models 
were  developed  independently.  Adjustment  and  alignment  of  these  two  sets  of  data  models  will 
be  required  to  make  them  compatible  at  the  conceptual  scheme  level. 

The  PSA  and  ETM  data  models  should  become  the  major  components  of  both  the  CALS 
IPDB/IWSDB  and  AECMA  CSDB. 
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6.0  INTEGRATION  OF  AECMA  lOOOD  AND  MIL-D-87269  (lETMDB) 


AECMA  lOOOD  is  designed  for  use  within  the  European  aerospace  industry  to  acquire 
format-free  technical  information  in  the  form  of  standardized  data  modules  (DMs)  for  the  creation 
and  updating  of  technical  documents  on  different  media.  The  DM  is  loaded  into  a  Common 
Source  Data  Base  (CSDB)  via  SGML  DTDs.  AECMA  lOOOD  allows  an  entire  ETM  or  any 
required  single  DM  (a  part  of  the  document)  to  be  exacted  from  the  CSDB.  The  AECMA  lOOOD 
is  currently  being  expanded  to  allow  production  of  ETMs  and  lETMs. 

On  the  other  hand  the  MIL-D-87269  (lETMDB)  specification,  as  a  U.S.  DoD  supported 
effort,  specifies  the  requirements  for  an  interactive  electronic  technical  manual  data  base 
(lETMDB)  for  the  purpose  of  creating  an  interactive  electronic  technical  manual.  The  MIL-D- 
87269  specification  contains  a  comprehensive  set  of  SGML  generic  data  element  stmctures  such 
as  text,  graphics,  audio,  video,  and  links  to  external  processes.  This  external  link  provides 
capability  for  users  to  access  and  interact  with  the  data  base  content  through  the  electronic  display 
screen.  MIL-D-87269  was  not  developed  for  paper  publications. 

Each  of  these  two  specifications  contains  a  DTD  based  on  the  same  ISO  8879  (SGML) 
specification  for  a  neutral  data  base.  However,  these  two  DTDs  are  different  because  they  were 
designed  for  different  Technical  Documentation  structures.  The  AECMA  lOOOD  DTD  was 
designed  to  follow  MIL-M-28(X)1  as  close  as  possible.  For  ETM  and  lETM  within  the  AECMA 
lOOOD  environment,  MIL-D-87269  is  used  as  a  basic  reference  document.  Incompatibilities  will 
be  repotted. 

MIL-D-87269  does  not  requite  the  Format  Output  Specification  Instances  (FOSIs)  of 
MIL-M-28001  to  provide  machine-interpretable  ou^ut  processing  information  for  printing  or 
interactive  electronic  delivery.  On  the  other  hand,  MIL-M-28001  does  not  enforce  the 
development  of  a  content-tagged  and  nonduplicative  data  base  as  does  MIL-D-87269.  MIL-M- 
28001  instead  relies  on  the  DTD  to  address  these  requirements. 

Th  AECMA  KXXID  and  MIL-D-87269  specifications  should  be  made  compatible  so  that 
any  presentation/delivery  systems  can  use  either  data  base.  The  obvious  approach  appears  to  be 
combining  these  two  speciflcations  into  a  single  one.  It  would  specify  the  development  of 
flexible,  neutral,  content-oriented,  and  nonduplicative  SGML  data  bases.  It  could  use  HyTime 
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(Ref.  18)  and  DSSSL  (Ref.  19)  to  enable  the  output  systems  to  provide  both  interactive  electronic 
and  printed  media. 

The  CALS/ISG  Electronic  Publication  Conunittee  (EPC)  is  investigating  the 
incorporation  of  lETM  concepts  and  guidelines  into  MIL-M-28001 .  (Refs.  35  to  38,  and  5 1 ) 


7.0  DTDS  FOR  THE  TRAINING  MATERIAL 


The  costs  of  providing  separate  hardware  and  software  systems  for  ETMs,  computer- 
aided  training  (CAT)  and  automatic/electronic  test  (ATE)  equipment  are  high.  In  many  instances, 
space  is  not  available  for  separate  systems.  There  are  currently  no  CALS  specification  which 
enables  the  electronic  integration  of  ETMs,  CAT,  and  ATE.  Reference  59  suggests  that  a  list  of 
data  elements  be  provided  for  training  material  development.  A  set  of  SGML  generic  data 
element  structures  and  DTDs  for  the  training  material  should  be  developed  as  shown  in  Fig.  9. 


8.0  INTEGRATION  OF  AECMA2000M  AND  MIL-STD-1388-2B 


AECMA  2000M  was  prepared  for  military  aircraft  systems.  Its  scope  is  limited  to  the 
material  management  process,  because  it  addresses  processes  and  data  related  to  parts 
provisioning,  i.e.,  initial  provisioning,  initial  provisioning  list  (IPL),  illustrated  parts  catalogues 
(IPC),  procurement  planning,  order  administration,  and  invoicing. 

MIL-STD-1388-2B  (LSAR)  and  AI^MA  2000M  are  mutually  complementary  in  scope 
and  focus.  Because  LSAR  collects  its  data  as  part  of  the  system  engineering  management  process, 
the  resultant  LSAR  data  base  could  conceivably  provide  the  spareable  item  data  requited  by 
2()00M  for  the  Initial  Provisioning  Lists  (IPL)  and  Illustrated  Parts  Catalogues  (IPC)  construction. 

In  recent  years,  several  studies  concerning  the  the  harmonization  and  alignment  of  data 
elements  corresponding  to  these  two  standards  have  been  conducted. 
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A  detailed  study  has  been  conducted  by  the  Military  and  Industry  AECMA  MSWG 
2000M  and  LSA  study  group  to  analyze  the  overlap  between  AECMA  2000M  (Chapter  1 )  and 
MIL-Smi388-2B.  (Ref.  53) 

The  UK  Ministry  of  Defence  Standard  00-60  has  also  compared  the  data  elements  of 
AECMA  2000M  (Chapter  1)  and  MIL-STD-1388-2B,  and  has  created  a  UK  LSA  data  dictionary 
(Ref.  54).  This  dictionary  contains  harmonized  MIL-1388-2B  and  AECMA  2000M  DEDs  and 
additional  2000M  DEDs  where  harmonization  could  not  be  achieved. 

The  CALS  ISG/SALSA  committee  has  also  analyzed  and  compared  the  data  elements  of 
AECMA  2000M  and  MIL-STD-1388-2A/2B.  (Ref.  55) 

9.0  INTEGRATION  OF  AECMA  2000M  AND  MILSTRIP/MILSTRAP 


’  The  data  requirements  for  the  preparation  of  the  procurement  package  for  the  Order 
Administration  AP  will  include  the  Provisioning  Technical  Package  (PTD)  which  will  be 
provided  by  the  PSA  AP  (Box  4  in  Figure  8)  and  Engineering  Data  for  Provisioning  (EDFP) 
which  will  be  provided  by  the  TDP  AP  (Box  1  in  Fig.  8). 

This  Order  Administration  AP  is  the  result  of  the  integration  of  the  Provisioning 
Planning,  Order  Administration,  and  Invoicing  of  AECMA  20()0M  with  MIL-STRIP/STRAP. 

The  functionality  of  MIL-STRIP/STRAP  overlaps  that  of  AECMA  20(X)M  to  a  great 
extent.  Except  for  stock  replenishment  modeling,  both  standards  control  the  material 
flow/demand  between  a  contractor  and  a  customer.  By  redefining  the  roles  of  and  the  related  data 
for  both  customer  and  contractor  on  an  operative  functional  level,  both  standards  can  be 
harmonized. 
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10.0  DATA  DICTIONARY 


After  the  various  data  models  (Boxes  3. 4,  and  5)  have  been  developed  and  integrated,  a 
consistent  data  element  dictionary  which  encompasses  all  the  data  models  will  be  a  natural 
output.  DoD  8320.1-M-l  (Ref.  IS)  should  be  regarded  as  the  guiding  document  for  the 
development  of  this  data  element  dictionary. 
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APPENDIX  G  .  RELATED  ACTIVITIES 


1.0  HARMONIZATION  WORKSHOP: 


The  internationalization  of  CALS  took  a  major  step  forward  with  the  completion  of  the 
Acquisition  Logistics  Standards  Harmonization  Assessment  Workshop  sponsored  by  the  NATO 
Armaments  Conunittee  301  Subgroup  D  on  CALS.  The  workshop  was  chaired  by  the  UK 
delegate  to  AC  301  and  was  hosted  by  France  in  March  and  April  1993.  The  workshop  addressed 
the  following  elements  of  Acquisition  Logistics:  (a)  Logistic  Support  Analysis  (LSAR);  (b) 
Provisioning;  (c)  Order  Administration;  (d)  Technical  Documentation  ;  and  (e)  EDI.  Some  fifty 
members  participated,  drawn  from  France,  Germany,  Italy,  Spain,  the  United  States,  and  the 
United  kingdom. 

The  major  standards  considered  were  the  U.S.  military  standards  MIL-STD- 1388/1 A  and 
2B,  MIL-M-87268,  MIL-D-87269,  and  MIL-Q87270  as  well  as  AECMA  Spec  2000M.  and 
AECMA  lOOOD.  The  workshop  also  considered  the  business  process  in  the  context  of  EDI  and 
examined  ANSI  X.  12,  EDIFACT,  and  the  EDI  elements  of  Spec  2000M.  The  core  CALS 
standards  of  MIL-STD-1840B  and  the  MIL-X-28000  series  of  specifications  completed  the  scope 
of  this  study. 

The  workshop  found  out  that  it  is  technically  feasible:  to  harmonize  and  integrate  these 
existing  standards  and  specifications  to  enable  NATO  to  exchange  data  for  CALS.  The  process 
and  data  requirements  examined  were  also  seen  to  have  applications  for  dual  civilian  and  military 
use.  It  is  recommended  that  the  standards  and  specifications  discussed  evolve  into  a  consistent  set 
of  international  standards,  such  as  the  ISO  STEP  standards.  For  more  detailed  information,  see 
Ref.  51. 
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2.0  NIAG  CALS  STUDY 


Following  a  DoD  CALS  presentation  to  NATO  in  early  1989,  the  NATO  Industry 
Advisory  Group  (NIAG)  decided  to  undertake  a  formal  study  to  determine  a  policy  fostering  the 
development  and  implementation  of  CALS  standards  and  methods  for  all  NATO  countries. 

More  than  forty  technical  experts  from  Europe  and  Canada  were  invited  to  participate  in 
this  study.  The  study  began  in  late  1990  and  ended  in  October  1991.  The  report  produced  by  this 
study  is  "A  NATO  Industry  Advisory  Group  Report  on  the  Applicability  of  CALS  to  the  NATO 
countries”  (Ref.  52).  The  study  was  performed  by  four  teams;  (1)  CALS  technical  standards,  (2) 
CALS  functional  aspects,  (3)  network  infrastructure,  and  cost  benefit  analysis.  Some  of  the 
recommendations  of  this  report  are; 

a.  NATO  should  respond  positively  to  the  U.S.  DoD  CALS  initiative,  and  should  also 
develop  a  strategy  which  promotes  a  CALS-style  concept  within  the  defense  agencies  of  all 
NATO  countries. 

b.  NATO  should  actively  seek  an  agreement  between  Europe  and  the  U.S.  to  publish, 
maintain,  and  promote  a  single  comprehensive  set  of  standards  to  support  the  CALS-type 
philosophy. 

c.  Because  the  implications  of  CALS  are  i  jbal,  NATO  standards  should  be 

regarded  as  forerurmers  to  comprehensive  ISO  standards  which  will  support  both  defense  and 
commercial  applications. 

d.  European  collaborative  projects  should  be  selected  as  lead  demonstrations. 

e.  The  procurement  policies  of  various  NATO  countries  should  be  reviewed. 

f.  A  NATO  recommendation  for  a  standard  generic  concurrent  engineering  model  should 
be  developed. 

g.  A  standard  set  of  ILS  requirements  should  be  developed. 
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h.  A  standardized  breakdown  of  project  phases  into  standard  tasks  and  data  sets  should 
be  developed. 

i.  CALS-type  education  should  be  actively  supported. 
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APPENDIX  H  -  RELATED  STEP  AP  DEVELOPMENTS 


1 .0  PRODUCT  SUPPORT  ANALYSIS  AP 


An  ISO  STEP  Product  Support  Analysis  (PSA)  AP  is  being  proposed  to  define  the  data 
requirements  for  ensuring  reliable,  maintainable,  and  supportable  products  at  minimum  cost  by 
integrating  logistic  support  considerations  into  the  evolving  design,  manufacturing,  and  support 
efforts.  The  development  of  the  PSA  AP  suite  is  based  on  the  harmonization  of  the  U.S.  military 
standard  MIL-STD-1388-2B  (LSAR)  and  European  specification  AECMA  20(X)M.  MIL-STD- 
1388  has  been  required  for  DoD  equipment  procurement  since  1983. 

Due  to  the  increasing  complexity  of  product  design  and  the  associated  maintenance 
requirements,  it  is  essential  that  the  product's  supportability  characteristics  be  incorporated  into 
the  product's  design  and  also  that  the  associated  maintenance  support  be  developed  on  an 
integrated  basis.  Operational  and  maintenance  support  requirements  should  be  planned  as  early  as 
possible  and  be  integrated  into  the  total  engineering  design  effort.  This  approach  ensures  the 
optimum  balance  between  the  product's  performance  and  its  associated  maintenance  support 
services.  To  achieve  these  objectives,  a  n  integrated  data  base  is  required  to  integrate  logistics 
related  engineering  information.  The  PSA  AP  is  proposed  to  meet  these  needs.  The  PSA  AP 
process  is  a  structured  methodology  used  by  systems  engineering  to  identify  the  supportability 
characteristics.  The  PSA  AP  facilitates  the  early  identification  of  the  supportability  characteristics 
in  the  design  and  subsequent  integration. 

International  commerce  and  government  industries  do  not  at  present  have  a  standardized 
mechanism  to  exchange  product  logistic  support  information.  These  industries  have  a  strong  need 
to  communicate  supply  support  or  provisioning  information.  Today's  "Just  in  Time"  support 
environments  depend  upon  the  r^id  procurement  of  parts  and  supplies.  This  need  requires  that 
the  communication  of  procurement  requirements  be  integrated  with  an  organization’s  product 
definition  data  base.  Such  communications  are  currently  performed  in  a  manual  and  paper  fashion 
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that  is  very  time  consuming,  error  prone,  and  labor  intensive.  A  more  cost  effective  means  is 
needed  to  address  the  following: 


The  maintainability  and  supportability  analysis  of  the  product. 

The  maintenance  tasks  required  to  support  the  operation  of  the  product. 

The  skills  and  training  required  to  support  the  maintenance  of  the  product. 

The  parts,  material,  special  tools,  and  equipment  required  to  support  the 
maintenance  of  the  product. 

The  technical  publications  required  to  support  the  maintenance  of  the  product. 
The  transportation,  facility,  packaging,  and  preservation  to  support  the  product. 
The  recyclability  and/or  disposal  of  the  maintained  product  and  its  by-products. 


2.0  TECHNICAL  DATA  PACKAGE  AP 

The  purpose  of  the  Technical  Data  Package  (TDP)  AP  is  to  define  the  common  set  of 
requirements  for  the  operation  and  life-cycle  support  hinctions  for  DoD  weapon  systems.  These 
functions  include:  (1)  re-procurement,  (2)  re-manufacturing,  (3)  retrofit/modification,  and  (4) 
repair  as  representative  functions  from  which  a  set  of  common  needs  could  be  derived.  This 
initial  TDP  AP  scope  will  exclude  requirements  for  technical  manuals,  and  engineering  analysis. 

Based  on  these  DoD  wetqxrn  system  requirements,  the  initial  focus  will  fall  primarily  into 
three  major  categories;  (1)  structural  (e.g.,  mechanical  parts,  assemblies,  etc.);  (2)  electronics;  and 
(3)  electrical  components.  The  MIL-T-31000,  MIL-STD-881  A,  MIL-STD-1840,  and  MIL-D- 
28000  ate  major  standards  of  defining  the  content,  delivery,  and  representation  for  technical  data 
on  DoD  wetqron  system  procurement.  The  TDP  AP  will  support  the  structure  and  basis 
requirements  of  these  military  standards. 

This  TDP  AP  is  sponsored  by  the  DoD  CALS/CE  office,  AF  F-22  program  office,  and 
AF  ManTech  program  office.  This  program  is  managed  by  NIST. 
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APPENDIX  I  -  REFERENCED  STANDARDS  AND  SPECIFICATIONS 


1.0MIL-STD-1388-2B:  LSAR  (LOGISTIC  SUPPORT  ANALYSIS  RECORD) 


The  intent  of  MIL-STD- 1388-1  is  to  ensure  reliable,  maintainable,  and  supportable 
weapon  systems  at  minimum  cost  by  integrating  logistic  support  considerations  into  the  evolving 
design  effort.  It  is  a  dynamic,  real-time  interactive  process  requiring  concurrence  of  the  design, 
engineering  analysis,  and  product  support  planning  functions.  As  a  result,  addressing  logistics 
requirements  becomes  part  of  the  design  process,  rather  than  occuring  after  design  decisions  that 
excluded  support  requirements  have  been  made. 

MIL-STD- 1388-2B  defines  the  format  and  content  of  the  LSAR  and  the  structure  of 
various  standard  reports  that  deliver  data  in  digital  form.  It  consolidates  logistics  oriented 
technical  information  with  data  from  the  various  engineering  disciplines  and  integrated  logistic 
support  elements  to  reduce  redundancy,  facilitate  timely  usage,  and  promote  consistency  of  data 
elements  from  the  various  disciplines. 

The  MIL-STD- 1388-2B  data  are  organized  in  a  relational  data  base  format.  The  use  of 
relational  DBMS  and  tables  offers  many  benefits,  among  which  are  ad  hoc  report  generation  and 
a  more  practical  method  of  on-line  access.  Because  the  MIL-STD- 1388-2B  data  base  is  already 
logically  integrated,  the  use  of  other  software  tools  as  well  as  linkage  with  other  related 
engineering  data  bases  is  encouraged.  For  detail  information,  see  Ref.  2. 


2.0  MIL-M-28001 :  SGML  (STANDARD  GENERAL  MARKUP  LANGUAGE) 


The  MIL-M-28001  military  specification  is  the  DoD  implementation  of  the  ISO  8879 
SGML  and  establishes  requirements  for  the  digital  interchange  of  technical  publication  text.  Data 
prepared  in  conformance  to  MIL-M-28001  will  facilitate  the  automated  stor^e,  retrieval, 
interchange,  and  processing  of  technical  documents  from  heterogeneous  data  sources. 
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MIL-M-28001  defines  both  a  methodology  and  a  high  level  computer  language  for 
document  representation.  It  provides  coherent  and  unambiguous  grammar  and  syntax  for 
describing  what  a  user  chooses  to  identify  within  a  document.  Regardless  of  the  type  of  document 
or  the  nature  of  the  document's  text,  it  provides  a  formal  markup  procedure,  that  is  also 
independent  of  the  system  and  output  environments  used  for  this  purpose.  The  definition  of  the 
document's  structure  or  content  in  terms  of  elements,  their  attributes,  entities,  and  other 
components  is  called  a  "Document  Type  Definition"  (DTD).  A  DTD  defines  the  structure  or 
content  of  a  specific  class  of  document.  For  detail  information,  s'^e  Ref.  4. 


3.0  MIL-D-87269:  lETMDB  (INTERACTIVE  ELECTRONIC  TECHNICAL  MANUL 
DATA  BASE) 


The  MIL-D-87269  military  specification  defines  requirements  for  the  weapon  system 
related  data  base  from  which  lETMs  or  view  packages  are  to  be  constructed.  The  data  base 
elements  are  defmed  using  SGML. 

lETMs  ate  the  paperless  functional  equivalent  of  conventional  p^r  based  TMs  and  will 
ultimately  replace  some  of  those  paper  TMs  in  the  field.  This  specification  provides  guidance  for 
the  acquisition  of  lETMs  and  associated  support  data  bases  by  a  DoD  program  manager.  The 
extent  to  which  automated  access  and  presentation  techniques  are  utilized  in  lETMs  is  such  that 
this  CALS  specification  will  not  be  a  simple  extension  of  the  paper-based  TM  specifications,  but 
will  be  a  new  category  of  specification  in  the  CALS  program.  For  detail  information,  see  Ref.  3. 


4.0  AECMA  SPEC  2000M:  MATERIAL  PROVISIONING  AND  MANAGEMENT 


By  using  uniform  formats  in  providing  weapon  system  related  logistics  data,  the  AECMA 
Specification  2000M  defines  the  materiel  management  processes  and  procedures  to  be  used  in 
support  of  aircraft  and  other  aerospace  airborne,  and  ground  equipment  supplied  to  military 
customers.  Specification  2000M  is  the  equivalent  of  ATA  2000  and  parts  of  ATA  1(X)  which  are 
used  to  support  airline  aircraft.  Although  the  ATA  Spec  2000  was  used  as  a  basis  for  the  AECMA 
2000M  development,  different  military  policies  and  requirements  prevented  the  European 
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military  aaoption  of  the  civil  specification.  Nevertheless,  the  development  of  a  single  common 
specification  for  both  military  and  civilian  use  remains  the  ultimate  goal  of  AECMA  and  ATA. 

Spec  2000M  covers  the  procedures  related  to: 

a.  Provisioning  -  defines  the  process  and  specifies  the  data,  formats  and  transmission 
procedures  to  be  used  in  providing  provisioning  information  to  the  customer.  It  provides  the  data 
base  from  which  Illustrated  Parts  Catalogues  are  produced. 

b.  NATO  codification  -  defines  the  processes  and  information  flow  for  all  activities 
related  to  Codification. 

c.  Procurement  Planning,  Order  Administration,  and  Invoicing  -  defines  methods  for 
industry  to  piovide  part  information  for  sale  and  quotation  processes,  as  well  as  order  placement 
and  deliveries.  It  also  provides  a  standard  process  of  transmitting  invoice  data. 

d.  Information  Exchange  -  covers  the  exchange  of  spares  consumption  data  between 
customers  and  industry  as  well  as  the  transmission  of  repair  arising  forecast  information. 

For  detail  information,  see  Ref.  5. 


5.0  AECMA  SPEC  lOOOD:  TECHNICAL  PUBLICATION 


The  AECMA  Specification  lOOOD  has  been  produced  to  establish  standards  for  technical 
documentation  of  air  vehicle  or  associated  equii^ment  and  to  provide  a  definition  of  an 
information  data  base.  The  data  base  is  intended  to  provide  source  information  for  compilation  of 
the  data  required  for  technical  documentation.  It  is  referred  to  as  the  Conunon  Source  Data  Base 
(CSDB). 

Specification  lOOOD  covers  technical  publications  for  air  vehicle  projects  with  the 
exception  of  Illustrated  Parts  Catalogues  which  are  addressed  by  AECMA  2000M  specification. 
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It  is  intended  that  this  specification  will  be  a  common  specification  used  by 
manufacturers  and  customers  for  both  civilian  and  military  air  vehicles.  In  addition  to  this 
primary  purpose,  the  Spec  lOOOD  is  planned  to  expand  to  land  and  sea  systems. 

Specification  lOOOD  has  already  been  stipulated  in  European  procurement  specifications, 
such  as  the  European  Fighter  Aircraft.  Data  modules  for  the  aircraft  have  been  coded  in  SGML 
and  illustrations  to  CALS  base  standards.  DTDs  use  the  tag  set  defined  in  MIL-M-28001,  with 
necessary  extensions  and  modifications.  See  Ref.  6. 


6.0  ATA  SPEC  100:  MANUFACTURERS  TECHNICAL  DATA 


The  ATA  f  pec  100  establishes  standards  for  the  presentation  of  certain  aircraft,  engine, 
and  component  manufacturing  data  required  for  support  of  such  products.  While  these  standards 
are  not  mandatory  per  se,  they  become  mandatory  to  the  extent  that  they  are  incorporated  into  the 
purchase  agreements  between  the  individual  suppliers  and  between  individual  suppliers  and 
operators.  These  standards  are  intended  to  minimize  the  cost  to  and  effort  expended  by  operators 
to  make  the  manufacturer's  data  compatible  with  the  needs  of  their  mechanics  and  other  support 
personnel.  See  Ref.  26. 


7.0  ATA  SPEC  2000:  DATA  BASE  AND  CUSTOMER  SUPPORT 


The  ATA  Spec  2000  is  an  international  specification  covering  procurement  transactions 
for  aircraft  material  acquisition,  as  well  as  support  and  repair  activities  which  enable  airlines  and 
their  suppliers  to  exchange  information,  using  a  common  language.  Its  purpose  is  to  provide  cost- 
effective,  state-of-the-art  methods  usable  by  the  widest  possible  population  of  companies.  More 
specifically.  Spec  2000  covers  initial  provisioning,  spares  procurement,  order  administration, 
invoicing,  inventory  forecasting,  performance  reporting,  repair  administration,  and  bar  coding. 
See  Ref.  27. 
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8.0  ISO  10744:  HYTIME  (HYPERMEDIAmME-BASED  STRUCTURING  LANGUAGE) 


HyTime  is  a  structured  language  for  representing  the  logical  structure  of  documents  with 
requirements  for  space  and  time  based  coordinates  and  addressing.  HyTime  is  based  on  SGML 
(ISO  8879),  and  uses  the  grammatical  and  syntactical  conventions  of  SGML.  HyTime  provides 
the  capability  to  package  information  objects  using  a  standardized  markup  language  whose 
structure  will  enable  nonsequential  access,  querying,  version  control,  and  long-time  maintenance 
despite  system  evolution  or  migration. 

The  HyTime  language  can  be  directly  applied  to  hypertext  and  multimedia  applications. 
These  include  the  design  and  encoding  of  information  for  lETMs,  online  review  of  existing 
documents  both  in  and  not  in  neutral  formats,  and  the  creation  of  large  interop>erable 
hyperdocument  libraries  or  design  data  bases.  See  Ref.  18. 
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